Mümkün olduğu kadar az tablo içeren bir veritabanı oluşturmak gerekli midir?

En az sayıda tablo içeren bir veritabanı yapısı oluşturmalı mıyız?

Her şeyin tek bir yerde kalacağı şekilde mi tasarlanmalı yoksa daha fazla masa olması uygun mu?

Yine de herhangi bir şeyi etkileyecek mi?

Bu soruyu soruyorum çünkü bir arkadaşım mediaWiki'de bazı veritabanı yapısını değiştirdi. Sonunda, 20 masa yerine sadece 8 kullanıyordu ve bunu yapmak 8 ayını aldı (üniversite ödeviydi).

DÜZENLE

Cevabı şu şekilde sonuçlandırıyorum: durumların istisnai hale gelinceye kadar tabloların boyutu önemli değil; bu durumda denormalizasyon yardımcı olabilir.

Cevaplar için herkese teşekkürler.

IGNORE tablo sayısını. Tasarımın doğru olması konusunda daha fazla endişe edin . En büyük endişeniz tablo miktarı ise, muhtemelen veritabanı sistemleri tasarlamamalısınız.

Arkadaşınızın sadece 8 masaya ihtiyacı varsa ve sistem bununla iyi çalışırsa, 8 doğru sayıdır ve geri kalan 12 kişi ne yaptıysa gerekli olmayabilir.

Muhtemel istisnalar, masa numaralarında katı sınırları olan özel ortamlar olabilir, ancak kafamın üstünde böyle bir sistemin somut bir örneğini düşünemiyorum.

Bir veritabanı tam olarak ihtiyaç duyduğu kadar tabloya sahip olmalıdır. Daha az, daha fazla değil.

Veritabanı tabloları, sınıfların yapması gerektiği gibi, Tek Sorumluluk İlkesine bağlı kalmalıdır. Her tablo, başlamak için birden fazla ilgili veri grubuyla ilgilenmemelidir. Performans bir yana, bu durum tüm hayvanların yönetilmesini kolaylaştırıyor, çünkü masaların kendisi daha küçük olacak. Bu, aynı zamanda daha iyi performans verir, çünkü daha küçük tabloların aranması ve birleştirilmesi daha hızlıdır.

Masa sayısı konusunda, ders sayısı konusunda endişelendiğinizden daha fazla endişe etmeyin - endişelenmeyin. Ne kadar yer kapladığına değil, iyi, temiz ve okunaklı kod yapmaya odaklanın. Refactor daha iyi hale getirmek için çalışan bir ürününüz olduğunda agresif bir şekilde - ve veritabanını da kastediyorum! Başka sorgularda olması gereken veya gerekmeyen vb. Sütunları göreceksiniz. Hangi sorguların en uzun sürdüğünü ve neden aldığını görmek için bir profil göreceksiniz ve gerçekten bir sorunsa bu konuları ele alıyorsunuz.

Bir iş başvurusu için bir üretim veritabanı yüzlerce hatta binlerce tablo içerebilir. İş gereksinimleri için ihtiyaç duyduğunuz tablo sayısına ihtiyacınız var. Yalnızca daha az sayıda tabloya sahip olmak adına tablo sayısını azaltmaya çalışmak genellikle sorgulanması daha zor, veri bütünlüğü sorunları olan ve normalize edilmiş bir veritabanından çok daha zor olan bir veritabanı ile sonuçlanacaktır.

Denormalizasyonun gerekli olduğu zamanlar vardır. Bu sadece ne yaptığını ve nedenini tam olarak bilen biri tarafından yapılmalıdır. Denomalize etmek çok kolaydır, bu nedenle sadece yıllarca veritabanı deneyimine sahip bir veritabanı uzmanı veya üst düzey uygulama geliştiricisi tarafından yapılmalıdır. Deneyimsiz bir kişi, en azından, tasarladığı herhangi bir veri tabanında deneyimsiz bir kişiyi işe almayı düşünmeyeceğim bir alan olan veri ambarını yapmadığınız sürece, üçüncü normal forma ulaşmaya çalışmalıdır.

İnsanlar birleştirme pahalı olduğu için masaları düşürdüğünü söylediğinde, genellikle cahildirler ya da kritik indeksleri eksik olan ya da büyük sütunlarda doğal anahtarlar kullanan kötü tasarlanmış veritabanları vardır. İlişkisel veritabanları birleştirme kullanmak üzere tasarlanmıştır ve FK'lar uygun bir şekilde dizine eklenmişse ve birleştirmek için küçük alanlar kullanıyorsa (tamsayılar en verimlidir) birleşme işlemleri oldukça verimli olabilir. Terrabyte büyüklüğünde veritabanlarına sahip büyük işletmelerin bir şekilde mükemmel performans elde etmeyi ve birleşimleri kullanabildiklerini unutmayın.

Hiçbir ciddi veritabanı tasarımcısı, daha az sayıda tablo istedikleri için tablo sayısını azaltmaya çalışmaz. Verilerin artık gerekmediğinden veya başka bir şekilde çözemediğiniz bir performans sorununa sahip olduğunuz için tablo sayısını azaltırsınız (ve bir tabloyu denormalize etme verileriniz için kapsamlı bir risk almadan önce denemeniz gereken birçok yol vardır ) .

Veritabanındaki her alan, tablo adı, sütun adı, birincil anahtar ve değerin birleşimi ile tanımlandığından, her zaman depolayan tek bir tablo halinde denormalize ederek tablo sayısını her zaman azaltabilirsiniz. Çok kullanışlı değil, ama tamamen mümkün.

Tablolar, verilerle ilgilenme konularına yardımcı olan soyut bir katmandır. Bu yüzden yaratıldılar. Bir şaka yaptım ama her veri kümesini bir ana tabloya indirebileceğinizi anlamak derhal neden yapmamanız gerektiğine işaret ediyor: çünkü tablolar size bir şey getiriyor. Kavramsal düzeyde, insanlar için seri hale getirilmiş verilerden daha kolay anlaşılır bir yapı getiriyorlar. Bunlar arasında, normalleştirme kavramını getiriyorlar: gereksiz verileri kaydetmekten kaçınmak ve çeşitli yerlerde bir şeyleri değiştirmek yerine, değişiklikler için tek bir puan vermek. Teknik düzeyde, veritabanları verilerle yapmak istediğiniz şeylerin çoğunu getirir, sayısız araç ve bunları uygular ve muhtemelen kendinizden daha fazlasını test eder. Veri türlerini, varsayılan değerleri, kullanıcı haklarını, endeksleri, yabancı anahtar kısıtlamalarını vb. Düşünün. Çok sayıda optimize edilmiş, hata ayıklanmış, kullanılmış, test edilmiştir. (Mükemmelliğe değil ama yine de.)

Bir veritabanı bir araç olduğundan, esas olan aracın nasıl kullanılacağına karar vermektir. Tablo sayısı önemli değil. Küçültme her zaman mümkündür ancak faydaları ortaya koyma pahasına. (Normalleştirme hakkında daha fazla şey okursanız, denormalize etmek için birkaç vakayla karşılaşırsınız - ancak o zaman bile sadece tablo sayısını göz ardı edip azaltmak yerine doğru kararlarla ilgilidir.)

Sen kullanmalısınız sağ tablo sayısını. Teorik olarak, bütün veritabanını denormalize ederek tek bir tablo tablosu ile yapabilirdiniz, ancak veritabanı kullanılamaz. Arkadaşınız ellerinde çok fazla zaman geçirmiş gibi geliyor.

Minimum masa sayısına sahip olmak beni çok tuhaf bir amaç olarak vuruyor.

Bir şemayı kesinlikle 20 tablodan 8'e düşürmek iyi bir şey olabilir (iyi yapılırsa birleşmeleri azaltabilir ve performansı artırabilir, kullanılmayan sütunları kaldırabilir vb.), Ancak ilerlemenin anlaşılmasını ve geliştirilmesini eşit olarak zorlaştırabilir.

Başka bir şekilde düşünmek normalleşmenin iyi bir şey olduğunu düşünüyor musunuz? Normalleştirme genellikle daha fazla sayıda tabloya yol açar ancak aynı zamanda daha fazla bakım yapılabilir çözümlere, veri çoğaltılmasını ve veri yönetimini kolaylaştırır.

Elbette daha yavaş performansa da yol açabilir (denormalize veri tabanının iyi tasarlanmış olduğu varsayılarak).

Sonuçta bu alanlarda gereksinimlerinizin ne olduğunu düşünmeniz gerekir, ancak varsayılan bir başlangıç ​​konumu olarak makul bir normalizasyon düzeyi için gidin ve bunun daha az tablonun bir çözüm olabileceği belirli sorunlara neden olup olmadığına bakın derim.

Sayı önemli değil. Tasarım Oradaki bazı sistemlere bak. Magento, PHPBB, vb. Sistemlerinde onlarca masa var ve gayet iyi çalışıyorlar.

Normalleştirme ve performans konusundaki endişelerin yanı sıra, bir uygulamanın kapsamını yönetmenin bir yolu olarak "başka bir tablo gerektirecek" ifadesini kullanabilirsiniz. Bu özellik yeni bir tablo ve her zaman, yükseltmelerde ve ilgili diğer tüm kodlamaları tasarlama, oluşturma, test etme, yönetme enerjisi ve çabasını gerektirecektir. Mevcut tablolara 5 alan eklemek (uygunsa) 5 sütun tablosundan çok daha kolaydır.

Tablo oluşturmayı en aza indirmeye çalışan bir veritabanı tasarlarsanız, kısa zamanda ani zorluk ve hatalarınızı kendi yollarınızda göreceksiniz.

Bir veritabanı tasarımı oluştururken tablo sayısı aklınızda ön planda olmamalıdır. Mantıklı ve ilişkisel olarak gitmeleri gereken şeyleri yerleştirin.

Tüm iş amaçları ve amaçları için bir arada durması gereken verileri birden fazla tabloya bölmeyi seçtiyseniz (örneğin, veritabanını normalleştirmek için), tablo sayısının önemli olduğunu ve performans üzerinde büyük bir etkisi olabileceğini düşünüyorum. Genelde bunu yaptığınızda, ihtiyacınız olan tüm verileri elde etmek ve bu şekilde yapılandırılmış yeterince büyük tablolar için performans hızlı bir şekilde azalır, JOIN Operations (veya SQL eşdeğeri) olmaya zorlanırsınız.

Ayrıntılara girmeyeceğim, ancak tablo sayısının performansı etkileyebileceği gerçeğinin, Cassandra, Mongo ve Google BigTable (sic!) Gibi noSQL veritabanlarının icat edilmesinin nedenlerinden biri olduğunu düşünüyorum. ve bu nedenle verilerin normalleştirilmemesini teşvik ediyorlar (ve dolayısıyla çok sayıda tablodan / koleksiyondan, vb. kaçınıyorlar).

Aynı şey, Apache'nin Solr gibi, dokümanlarınızı ortak alanlara sahip bir "bir" tümünü kapsayan "şemaya sahip olmanızı teşvik eden, birden fazla" tabloya "veya" giriş türüne "ayırmayı gerçekten teşvik etmeyen veya kolaylaştıran arama sunucuları için söylenebilir. Dizinlemek istediğiniz tüm belge türlerine (ve dolayısıyla JOIN benzeri işlemler yapmaktan kaçının).

Bir şemada x tablo olmasının basit gerçeğinin onu her zaman x / 2 tablolarla bir şemadan daha yavaş hale getireceğini söylemiyorum, ancak bunun sonucu olarak yavaşlamalara neden olabileceği bazı bağlamlar var. Tüm bu tablolardaki verileri toplamak için gereken ilave işlemler. Buna devam edersek, "herhangi bir sayıdaki tablo ve verilerin aşırı normalleşmesinin bu kadar performans üzerinde hiçbir etkisi olmadığını" söylemenin uygun olmadığını düşünüyorum.

Bob Amca, Daha Çok Basit olduğunu iddia ederdi.

Http://c2.com/cgi/wiki?FearOfAddingTables adresine bakın.

"İyi bir tasarım genellikle tablolar ekleyerek basitleştirilir"

Neredeyse bütün varlıkların çoktan çoğa olduğuna inanıyorum, bu da daha fazla masa gerektiriyor.

Kıta kodu ile bir ülke tablosu yapın. Oh, yapamazsınız çünkü aslında 8 kıtalararası ülke var. Para birimleri ile aynı. Panama iki kullanır.

O zaman cevap YES.

Ancak "minimum" tablo sayısının gerçek anlamı ne bağlıdır.

Örneğin (bir anti-örnek).

Bir sonraki nesneye sahipsem

1. kullanıcılar
2. müşteriler

ve her ikisi de aynı durumları (alanları) paylaşır ve bir güvenlik kısıtlaması yoktur, o zaman tek bir masa yapmak için daha uygundur.

1. table_persons

iki farklı masa

1. table_users
2. table_customers

eksileri table_persons'da olduğundan daha yeni bir alan eklememiz gerekecek (type_of_person).

Başka bir hata (gerçekten yapmak zorunda değilse hata) bir masayı "bölmek", şöyle okumak: tek bir masayı ikiye ayırmak.

1. table_persons

iki tabloda

1. table_info_persons
2. table_extra_info_persons

çünkü iki tabloyu birleştirmek için bazı sorguları zorluyorsunuz ve bu kötü.