MySQL: birden çok tablo mu yoksa çok sütunlu bir tablo mu?

Yani bu daha çok bir tasarım sorusu.

Bir birincil anahtarım var (kullanıcının kimliğini söyleyin) ve bu kullanıcıyla ilişkili tonlarca bilgim var.

Bilgiye göre kategorilere ayrılmış birden çok tablom mu olmalı yoksa çok sütunlu tek bir tablom mu olmalı?

Eskiden bunu yapmak için kullandığım yol, birden çok tabloya sahip olmaktı, örneğin, uygulama kullanım verileri için bir tablo, profil bilgileri için bir tablo, arka uç belirteçleri için bir tablo vb.

Son zamanlarda biri bana bunu bu şekilde yapmamanın daha iyi olduğunu ve çok sayıda sütun içeren bir masanın iyi olduğunu söyledi. Mesele şu ki, tüm bu sütunlar aynı birincil anahtara sahip.

Veritabanı tasarımında oldukça yeniyim, bu nedenle hangi yaklaşım daha iyi ve artıları ve eksileri nelerdir?

Bunu yapmanın geleneksel yolu nedir?

Herhangi bir zamanda bilgi bire birdir (her kullanıcının bir adı ve şifresi vardır), o zaman muhtemelen bir tabloya sahip olmak daha iyidir, çünkü sonuçları almak için veritabanının yapması gereken birleştirme sayısını azaltır. Bazı veritabanlarının tablo başına sütun sayısında bir sınırlama olduğunu düşünüyorum, ancak normal durumlarda bu konuda endişelenmem ve gerekirse daha sonra her zaman bölebilirsiniz.

Veriler bire çoksa (her kullanıcının binlerce kullanım bilgisi satırı varsa), yinelenen verileri azaltmak için ayrı tablolara bölünmelidir (yinelenen veriler depolama alanını, önbellek alanını boşa harcar ve veritabanının bakımını zorlaştırır. ).

Bunun nedenlerini derinlemesine tartıştığı için veritabanı normalleştirme hakkındaki Wikipedia makalesini ilginç bulabilirsiniz :

Veritabanı normalleştirme, fazlalık ve bağımlılığı en aza indirmek için ilişkisel bir veritabanının alanlarını ve tablolarını düzenleme sürecidir. Normalleştirme genellikle büyük tabloları daha küçük (ve daha az gereksiz) tablolara bölmeyi ve bunlar arasındaki ilişkileri tanımlamayı içerir. Amaç, verileri izole etmektir, böylece bir alana yapılan eklemeler, silmeler ve değişiklikler sadece bir tabloda yapılabilir ve daha sonra tanımlanan ilişkiler aracılığıyla veritabanının geri kalanına yayılabilir.

Normalden arındırma da dikkat edilmesi gereken bir şeydir, çünkü verilerin tekrarlanmasının daha iyi olduğu durumlar vardır (çünkü veri okurken veritabanının yapması gereken iş miktarını azaltır). Başlamak için verilerinizi olabildiğince normalleştirmenizi ve yalnızca belirli sorgulardaki performans sorunlarının farkındaysanız normalleştirmenizi şiddetle tavsiye ederim.

Büyük bir masa genellikle kötü bir seçimdir. İlişkili tablolar, ilişkisel veritabanının birlikte çalışmak üzere tasarlandığı tablolardır. Düzgün bir şekilde dizine eklerseniz ve performanslı sorgular yazmayı bilirseniz, iyi performans göstereceklerdir.

Tablolar çok fazla sütun aldığında, veritabanının bilgileri depoladığı sayfanın gerçek boyutuyla ilgili sorunlarla karşılaşabilirsiniz. Ya kayıt sayfa için çok büyük olabilir, bu durumda kullanıcıları mutsuz eden belirli bir kaydı oluşturamayabilir ya da güncelleyemeyebilirsiniz ya da (en azından SQL Server'da) özellikle bazı taşmalara izin verilebilir. veri türleri (bunu yapıyorsanız bir dizi kuralla birlikte bakmanız gerekir), ancak çok sayıda kayıt sayfa boyutunun dışına taşarsa, çok sayıda performans sorunları yaratabilirsiniz. Şimdi MYSQL'in sayfaları nasıl işlediği ve potansiyel sayfa boyutu çok büyüdüğünde bir sorununuz olup olmadığı, bu veritabanının belgelerine bakmanız gereken bir şeydir.

İyi bir örneğim var. Aşağıdaki ilişkiler kümesiyle aşırı Normalleştirilmiş veritabanı:

people -> rel_p2staff -> staff

ve

people -> rel_p2prosp -> prospects

İnsanların isimleri ve kişi ayrıntılarına sahip olduğu, personelin yalnızca personel kaydı ayrıntılarına sahip olduğu, potansiyel müşterilerin yalnızca olasılık ayrıntılarına sahip olduğu ve ilgili tablolar, personel ve olası müşterilerle bağlantı kuran kişilerden gelen yabancı anahtarların bulunduğu ilişki tablolarıdır.

Bu tür bir tasarım tüm veritabanı için devam eder.

Şimdi bu ilişki kümesini sorgulamak, her seferinde çok masalı birleştirme, bazen 8 veya daha fazla tablo birleştirme. 40000 insan kaydını geçtiğimiz için çok yavaşlamaya başladığında, bu yılın ortalarına kadar gayet iyi çalışıyordu.

Endeksleme ve tüm düşük asılı meyveler geçen yıl kullanılmıştı, tüm sorgular mükemmel olacak şekilde optimize edildi. Bu, belirli normalleştirilmiş tasarım için yolun sonudur ve yönetim şimdi 6 aylık bir süre içinde veritabanının yeniden yapılandırılmasının yanı sıra ona bağlı olan tüm uygulamanın yeniden oluşturulmasını onayladı. $$$$ Ah.

Çözelti için doğrudan bir ilişki var olacaktır people -> staffvepeople -> prospect

Bununla karşılaştım ve MySQL'i çok kullanan ve son zamanlarda Postgres'e geçen biri olarak, en büyük avantajlardan biri, Postgres'deki bir alana JSON nesneleri ekleyebilmenizdir.

Dolayısıyla, bu durumda iseniz, çok sayıda sütuna sahip büyük bir tablo arasında karar vermek ve onu bölmek zorunda değilsiniz, ancak sütunları JSON nesnelerine birleştirerek azaltabilirsiniz, örneğin adresin 5 sütun olması yerine, sadece tek ol. Ayrıca bu nesne için de sorgulama yapabilirsiniz.

Her şeyi tek bir tabloya koyarsanız bu soruları kendinize sorun, o kullanıcı için birden fazla satırınız olacak mı? Bir kullanıcıyı güncellemeniz gerekiyorsa, bir denetim izi tutmak ister misiniz? Kullanıcı bir veri öğesinin birden fazla örneğine sahip olabilir mi? (örneğin telefon numarası gibi) daha sonra bir öğe veya öğe kümesi eklemek isteyebileceğiniz bir durumunuz olacak mı? Evet cevabını verirseniz, büyük olasılıkla yabancı anahtar ilişkileri olan alt tablolara sahip olmak istersiniz.

Üst / alt tabloların avantajları, veri bütünlüğü, dizinler aracılığıyla performans (evet bunu düz bir masada da yapabilirsiniz) ve daha sonra bir alan eklemeniz gerekirse, özellikle gerekli bir alan olacaksa, IMO'nun bakımı daha kolaydır.

Eksileri tasarımı daha zor, sorgular biraz daha karmaşık hale geliyor

Ancak, büyük bir düz masanın uygun olacağı birçok durum vardır, bu nedenle karar vermek için durumunuza bakmanız gerekir.

Zaten bir çeşit veritabanı tasarımı yaptım. benim için veritabanı yönetimi ile sistemin zorluğuna bağlı; evet, yalnızca tek bir yerde benzersiz verilere sahip olmak doğrudur, ancak çok fazla kayıt içeren aşırı normalleştirilmiş veritabanıyla sorgu yapmak gerçekten zordur. Sadece iki şemayı birleştirin; tıpkı facebook, gmail vb. gibi bakımı zor olan çok büyük kayıtlara sahip olacağınızı düşünüyorsanız, büyük bir tablo kullanın. ve basit sistem için bir kayıt kümesi için farklı bir tablo kullanın ... peki bu sadece benim fikrim .. umarım yardımcı olabilir .. sadece yap..yapabilirsin ... :)

Bunu yapmanın geleneksel yolu, bir yıldız şeması veya kar tanesi şemasında olduğu gibi farklı tablolar kullanmak olacaktır. Howeevr, bu stratejiyi iki katına dayandırırım. Teoride, verinin yalnızca bir yerde olması gerektiğine inanıyorum, çünkü orada bahsettiğim şema işe yarayacak. Bununla birlikte, raporlama motorları ve BI takımları için sütunsal bir yaklaşımın, raporlama ihtiyaçlarını daha fazla desteklediği için çok faydalı olacağına da inanıyorum. İnfobright.org gibi sütunlu yaklaşımlar, her iki yaklaşımı da inanılmaz derecede yararlı kılan büyük performans kazanımları ve sıkıştırmaya sahiptir. Pek çok şirket, kuruluşta tek bir veritabanı mimarisine sahip olmanın tüm ihtiyaçlarını karşılamadığını fark etmeye başlıyor. Pek çok şirket, birden fazla veritabanı mimarisine sahip olma konseptini uyguluyor.

bence tek bir tabloya sahip olmak daha etkili ancak tablonun ilişkiyi, eğilimi ve aynı satırın değişkenlerindeki farkı gösterecek şekilde düzenlendiğinden emin olmalısınız. örneğin, tablo öğrencilerin yaşlarını ve notlarını gösteriyorsa, en yüksek puan alan kişiye en düşük puan alanla iyi bir şekilde farklılaşan ve öğrencilerin yaş farkı eşit olacak şekilde tabloyu düzenlemelisiniz.