Veritabanı Tasarımında Kötü Uygulamalar: Bu Hataları Siz mi Yapıyorsunuz?

Bir geliştirici olarak size mevcut koda dayalı bir görev verildiğinde, birçok zorlukla karşılaşmanız gerekir. Bu tür zorluklardan biri - çoğu zaman en zorlu olandan değil - bir uygulamanın veri modelini anlamayı içerir.

Normalde size bir anlam ifade etmesi uzun zaman alan kafa karıştırıcı tablolar, görünümler, sütunlar, değerler, saklı prosedürler, işlevler, kısıtlamalar ve tetikleyicilerle karşılaşırsınız. Ve bir kez yaptıklarında, saklanan bilgileri iyileştirmenin ve bunlardan yararlanmanın birçok yolunu fark etmeye başlarsınız.

Deneyimli bir geliştiriciyseniz, muhtemelen başlangıçta daha iyi yapılabilecek şeyleri, yani tasarım kusurlarını fark edeceksiniz.

Bu makalede, bazı yaygın veritabanı tasarımı kötü uygulamaları, neden kötü oldukları ve bunlardan nasıl kaçınabileceğiniz hakkında bilgi edineceksiniz.

Kötü Uygulama No. 1: Verilerin Amacını Görmezden Gelmek

Veriler daha sonra tüketilmek üzere saklanır ve amaç her zaman onu depolamak ve en verimli şekilde geri almaktır. Bunu başarmak için, veri tabanı tasarımcısının önceden verinin neyi temsil edeceğini, nasıl elde edileceğini ve hangi oranda elde edileceğini, operasyonel hacminin ne olacağını (yani, ne kadar veri beklendiğini) ve son olarak da bilmesi gerekir. , nasıl kullanılacak.

Örneğin, verilerin her gün manuel olarak toplandığı bir endüstriyel bilgi sistemi, bilginin gerçek zamanlı olarak üretildiği bir endüstriyel sistemle aynı veri modeline sahip olmayacaktır. Niye ya? Çünkü aynı dönemde milyonlarca kaydı yönetmekle karşılaştırıldığında ayda birkaç yüz veya binlerce kaydı işlemek çok farklıdır. Veri hacimleri büyük olacaksa, veri tabanının verimliliğini ve kullanılabilirliğini korumak için tasarımcılar tarafından özel dikkat gösterilmelidir.

Ancak, verinin amacı aynı zamanda normalleştirme düzeyini, veri yapısını, kayıt boyutunu ve tüm sistemin genel uygulamasını da etkilediğinden, elbette veri hacmi dikkate alınması gereken tek husus değildir.

Bu nedenle, oluşturacağınız veri sisteminin amacını tam olarak bilmek, veritabanı motorunun seçiminde, tasarlanacak varlıklarda, kayıt boyutu ve formatı ve veritabanı motoru yönetim politikalarında dikkate alınması gereken hususlara yol açar.

Bu hedefleri göz ardı etmek, yapısal ve matematiksel olarak doğru olmasına rağmen, temellerinde kusurlu tasarımlara yol açacaktır.

Kötü Uygulama No. 2: Kötü Normalleştirme

Bir veritabanı tasarlamak deterministik bir görev değildir; iki veritabanı tasarımcısı belirli bir problem için tüm kuralları ve normalleştirme ilkelerini takip edebilir ve çoğu durumda farklı veri düzenleri oluştururlar. Bu, yazılım mühendisliğinin yaratıcı doğasının doğasında vardır. Ancak, her durumda anlamlı olan bazı analiz teknikleri vardır ve bunları takip etmek, en iyi performansı gösteren bir veritabanına ulaşmanın en iyi yoludur.

Buna rağmen, çoğu zaman en temel normalleştirme kurallarına uyulmadan anında tasarlanan veritabanlarıyla karşılaşıyoruz. Şu konuda net olmalıyız: Varlıklarınızı en iyi temsil edecek ve performansı sorgulama ve ekleme-güncelleme-silme arasında en iyi dengelenecek olan düzen olduğundan, her veritabanı en azından üçüncü normal forma normalleştirilmelidir. .

3NF, 2NF ve hatta 1NF ile uyumlu olmayan tablolarla karşılaşırsanız, bu tabloları yeniden tasarlamayı düşünün. Bunu yapmak için harcadığınız çaba, çok kısa vadede karşılığını verecektir.

Kötü Uygulama No. 3: Fazlalık

Önceki noktayla çok ilgili, normalleştirmenin hedeflerinden biri onu azaltmak olduğundan, fazlalık oldukça sık görülen başka bir kötü uygulamadır.

Aynı bilgilerin birçok versiyonunu güncel tutmak için iş mantığı gerektirdiğinden, gereksiz alanlar ve tablolar geliştiriciler için bir kabustur. Bu, normalizasyon kurallarına tam olarak uyulursa önlenebilecek bir ek yüktür. Bazen fazlalık gerekli görünse de, yalnızca çok özel durumlarda kullanılmalı ve gelecekteki gelişmelerde dikkate alınabilmesi için açıkça belgelenmelidir.

Yedeklemenin tipik kötü etkileri, veritabanı boyutunun gereksiz yere artması, verilerin tutarsızlığa meyilli olması ve veritabanının verimliliğinde azalmadır, ancak daha da önemlisi, verilerin bozulmasına neden olabilir.

Kötü Uygulama No. 4: Kötü Referans Bütünlüğü (Kısıtlamalar)

Referans bütünlüğü, veri kalitesini en iyi seviyede tutmak için veritabanı motorlarının sağladığı en değerli araçlardan biridir. Tasarım aşamasında herhangi bir kısıtlama veya çok az kısıtlama uygulanmazsa, veri bütünlüğü tamamen iş mantığına dayanmak zorunda kalacak ve bu da onu insan hatasına açık hale getirecektir.

Kötü Uygulama No. 5: DB Motoru Özelliklerinden Yararlanmama

Bir veritabanı motoru (DBE) kullandığınızda, veri işleme görevleriniz için yazılım geliştirmeyi basitleştirecek ve bilgilerin her zaman doğru, güvenli ve kullanılabilir olmasını garanti edecek güçlü bir yazılım parçasına sahip olursunuz. Bir DBE aşağıdaki gibi hizmetler sağlar:

• Verilerinize bakmanın hızlı ve verimli bir yolunu sağlayan görünümler, genellikle veri doğruluğunu kaybetmeden sorgu amaçları için normalleştirmez.
• Tablolardaki sorguları hızlandırmaya yardımcı olan dizinler.
• Programlama olmadan bilgileri analiz etmeye yardımcı olan toplu işlevler.
• Beklenmeyen bir şey olursa, tümü yürütülen ve taahhüt edilen veya iptal edilen (geri alınan) ve böylece bilgileri sürekli olarak doğru durumda tutan, veri değiştiren cümlelerin işlemleri veya blokları.
• İşlemler yürütülürken verileri güvenli ve doğru tutan kilitler.
• Karmaşık veri yönetimi görevlerine izin vermek için programlama özellikleri sağlayan saklı yordamlar.
• Karmaşık hesaplamalara ve veri dönüştürmelerine izin veren işlevler.
• Veri doğruluğunu garanti etmeye ve hataları önlemeye yardımcı olan kısıtlamalar.
• Verilerde olaylar meydana geldiğinde eylemleri otomatikleştirmeye yardımcı olan tetikleyiciler.
• Başlık altında çalışan, her cümlenin en iyi şekilde yürütülmesini sağlayan ve yürütme planlarını gelecekteki durumlar için tutan komut optimize edici (yürütme planlayıcı). Yürütme planları DBE'de kalıcı olarak tutulduğundan, görünümleri, saklı yordamları ve işlevleri kullanmanın en iyi nedenlerinden biri budur.

Bu yetenekleri bilmemek veya görmezden gelmek, geliştirmeyi son derece belirsiz bir yola ve kesinlikle hatalara ve gelecekteki sorunlara götürecektir.

Kötü Uygulama No. 6: Bileşik Birincil Anahtarlar

Bu biraz tartışmalı bir nokta, çünkü günümüzde pek çok veritabanı tasarımcısı, iki veya daha fazla alanın birleşimiyle tanımlanan bileşik bir anahtar yerine, tamsayı kimliği otomatik olarak oluşturulan bir alanı birincil anahtar olarak kullanmaktan bahsediyor. Bu şu anda “en iyi uygulama” olarak tanımlanıyor ve kişisel olarak buna katılma eğilimindeyim.

Bununla birlikte, bu sadece bir kuraldır ve elbette DBE'ler, birçok tasarımcının kaçınılmaz olduğunu düşündüğü bileşik birincil anahtarların tanımlanmasına izin verir. Bu nedenle, artıklıkta olduğu gibi, bileşik birincil anahtarlar bir tasarım kararıdır.

Ancak, bileşik birincil anahtara sahip tablonuzun milyonlarca satıra sahip olması bekleniyorsa, bileşik anahtarı kontrol eden dizin, CRUD işlem performansının çok düştüğü bir noktaya kadar büyüyebilir. Bu durumda, dizini yeterince kompakt olacak ve benzersizliği korumak için gerekli DBE kısıtlamalarını oluşturacak basit bir tamsayı kimliği birincil anahtarı kullanmak çok daha iyidir.

Kötü Uygulama No. 7: Kötü İndeksleme

Bazen birçok sütuna göre sorgulamanız gereken bir tablonuz olur. Tablo büyüdükçe, bu sütunlardaki SELECT'lerin yavaşladığını fark edeceksiniz. Tablo yeterince büyükse, mantıksal olarak, bu tabloya erişmek için kullandığınız her sütunda bir dizin oluşturmayı, yalnızca SEÇİM'lerin performansının arttığını ancak EKLEME'lerin, GÜNCELLEME'lerin ve DELETE'lerin düştüğünü hemen hemen bulmak için düşüneceksiniz. Bu, elbette, dizinlerin tabloyla senkronize tutulması gerektiği gerçeğinden kaynaklanmaktadır, bu da DBE için büyük ek yük anlamına gelmektedir. Bu, birçok şekilde çözebileceğiniz tipik bir aşırı indeksleme durumudur; örneğin, tabloyu sorgulamak için kullandığınız birincil anahtardan farklı tüm sütunlarda yalnızca bir dizin olması, bu sütunları en çok kullanılandan en az kullanılana doğru sıralamak, tüm CRUD işlemlerinde sütun başına bir dizinden daha iyi performans sunabilir.

Öte yandan, sorgulamak için kullanılan sütunlarda indeksi olmayan bir tabloya sahip olmak, hepimizin bildiği gibi, SELECT'lerde düşük performansa yol açacaktır.

Ayrıca, dizin verimliliği bazen sütun türüne bağlıdır; INT sütunlarındaki dizinler mümkün olan en iyi performansı gösterir, ancak VARCHAR, DATE veya DECIMAL üzerindeki dizinler (eğer mantıklıysa) o kadar verimli değildir. Bu düşünce, mümkün olan en iyi verimlilikle erişilmesi gereken tabloların yeniden tasarlanmasına bile yol açabilir.

Bu nedenle, indeksleme her zaman hassas bir karardır, çünkü çok fazla indeksleme çok az kadar kötü olabilir ve indekslenecek sütunların veri türünün nihai sonuç üzerinde büyük bir etkisi vardır.

Kötü Uygulama No. 8: Kötü Adlandırma Kuralları

Bu, programcıların mevcut bir veritabanıyla karşı karşıya kaldıklarında her zaman mücadele ettikleri bir şeydir: tablo ve sütun adlarıyla hangi bilgilerin depolandığını anlamak, çünkü çoğu zaman başka bir yol yoktur.

Tablo adı hangi varlığı içerdiğini açıklamalı ve her sütun adı hangi bilgiyi temsil ettiğini açıklamalıdır. Bu kolaydır, ancak tabloların birbiriyle ilişkilendirilmesi gerektiğinde karmaşıklaşmaya başlar. Adlar dağınık olmaya başlar ve daha da kötüsü, mantıksız normlarla kafa karıştırıcı adlandırma kuralları varsa (örneğin, "sütun adı 8 karakter veya daha az olmalıdır"). Nihai sonuç, veritabanının okunamaz hale gelmesidir.

Bu nedenle, veritabanının desteklediği uygulama ile kalıcı olması ve gelişmesi bekleniyorsa, bir adlandırma kuralı her zaman gereklidir ve burada özlü, basit ve okunabilir bir tane oluşturmak için bazı yönergeler verilmiştir:

• Tablo veya sütun adı boyutunda sınırlama yoktur. Tanımlayıcı bir isme sahip olmak, kimsenin hatırlamadığı veya anlamadığı bir kısaltmadan daha iyidir.
• Eş olan isimler aynı anlama gelir. Aynı ada sahip ancak farklı tür veya anlamlara sahip alanlara sahip olmaktan kaçının; bu er ya da geç kafa karıştıracaktır.
• Gerekmedikçe fazlalık yapmayın. Örneğin, "Item" tablosunda "ItemName", "PriceOfItem" veya benzer adlar gibi sütunların olmasına gerek yoktur; “Ad” ve “Fiyat” yeterlidir.
• DBE ayrılmış kelimelere dikkat edin. Bir sütuna SQL'e ayrılmış bir kelime olan "Index" adı verilecekse, "IndexNumber" gibi farklı bir sütun kullanmayı deneyin.
• Basit birincil anahtar kuralına bağlı kalıyorsanız (otomatik olarak oluşturulan tek tamsayı), her tabloda "Id" olarak adlandırın.
• Başka bir tabloya katılıyorsanız, gerekli yabancı anahtarı “Id” adında bir tamsayı ve ardından birleştirilmiş tablonun adı (örn. IdItem) olarak tanımlayın.
• Kısıtlamaları adlandırıyorsanız, kısıtlamayı açıklayan bir önek (örneğin, "PK" veya "FK") ve ardından ilgili tablo veya tabloların adını kullanın. Elbette, alt çizgi (“_”) kullanmak, işleri daha okunaklı hale getirmeye yardımcı olur.
• Dizinleri adlandırmak için, “IDX” önekini ve ardından tablo adını ve dizinin sütununu veya sütunlarını kullanın. Ayrıca, dizin benzersizse önek veya sonek olarak "EŞSİZ" kullanın ve gerektiğinde alt çizgi yapın.

İnternette veritabanı tasarımının bu çok önemli yönüne daha fazla ışık tutacak birçok veritabanı adlandırma yönergesi vardır, ancak bu temel kurallarla en azından okunabilir bir veritabanına ulaşabilirsiniz. Burada önemli olan isimlendirme yönergelerinizin boyutu veya karmaşıklığı değil, onları takip etmedeki tutarlılığınızdır!

Bazı Son Notlar

Veritabanı tasarımı, bilgi ve deneyimin birleşimidir; yazılım endüstrisi ilk günlerinden beri çok gelişti. Neyse ki, veritabanı tasarımcılarının en iyi sonuçları elde etmesine yardımcı olacak yeterli bilgi var.

İnternetin her yerinde iyi veritabanı tasarım yönergelerinin yanı sıra kötü uygulamalar ve veritabanı tasarımında kaçınılması gereken şeyler vardır. Sadece seçiminizi yapın ve ona sadık kalın.

Ve unutmayın, yalnızca deneyler, hatalar ve başarılar yoluyla öğrenirsiniz, o yüzden devam edin ve şimdi başlayın.