Değişken sütunlarla tablo tasarımı nasıl işlenir

Bir tablo tasarım senaryom var ve DBA olmayan bir tür olarak, hangi daha ölçeklenebilir görüş istiyorum.

Diyelim ki küçük bir mahalle (200 ev) ile başlayıp sonunda 5000000+ eve kadar büyüyen bir metro alanı için evler hakkında bilgi kaydetmeniz istendi.

Temel bilgileri saklamanız gerekir: ID # (Benzersiz bir dizin olarak kullanabileceğimiz benzersiz bir lot #), Addr, City, State, Zip. Güzel, basit masa bunu halledecek.

Ancak her yıl, tüm evler hakkında ekstra bilgi kaydetmeniz istenecektir - ve her yıl NE bilgileri değişecektir. Bu nedenle, örneğin, ilk yıl, sahiplerin soyadını ve kare görüntülerini kaydetmeniz istenir. İkinci yıl, soyadı tutmanız istenir, ancak kare görüntüleri dökün ve bunun yerine sahiplerin adlarını toplamaya başlayın.

Son olarak - her yıl fazladan sütun sayısı değişecektir. 2 ekstra sütunla başlayabilir, ardından gelecek yıl 6'ya, ardından 2'ye geri dönebilir.

Bu yüzden bir tablo yaklaşımı, özel tabloları ev tablolarına sütun olarak eklemeye çalışmaktır, böylece yalnızca bir tablo vardır.

Ama birinin bunun için tabloları ortaya koyduğu bir durum var:

"Ev Masası" sütunları: ID, Addr, Şehir, Eyalet, Zip - ev başına bir satır ile

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

"Özel Bilgi Tablosu" sütunları: Kimlik, Ad, Değer - tablo aşağıdaki gibi görünür:

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage 

Yani her ev kaydı için birden fazla satır var. Her yıl isteğe bağlı bilgiler değiştiğinde, bu tablo tam anlamıyla yeniden oluşturulur, bu nedenle gelecek yıl şöyle görünebilir:

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

Sonunda 100.000 ev sırası toplarsınız ve bir yıl 10 ekstra bilgi daha vardır; şimdi ikinci tablo, birçoğu gereksiz (açıklama) bilgiye sahip 1.000.000 satırlık bilgidir. Veritabanı gereklilikleri genel olarak, insanların günlük satır sayısı + ilişkili satır alanı bilgileri + ilişkili özel alan değerlerini almaları gerekecek olmasıdır.

Yani sorum: Bunun yerine aşağıdakilerden birini yapmak kötü olur (ya da korkunç):

A) Ev tablosunu maksimum özel sütun sayısını (belki "1" ila "10" olarak adlandırılır) tahmin ederek düzenleyin ve bu özel değerleri doğrudan ev satırlarına ekleyin

VEYA

B) Özel bilgileri ev tablosunda saklayın, ancak her yıl gereksinimler değiştiğinde, ev tablosunu yalnızca özel bilgiler için gereken sütun sayısı ile, gereksinimlerin somunlaşabileceği ve asla maksimum maksimum isteğe bağlı alanlar istenebilir mi?

Teşekkürler, umarım bu mantıklıdır!

Hemen hemen 4 seçeneğiniz var:

NoSQL - tanım Her kayıt bir Anahtar / Değer çifti grubu olarak saklanır. Çok esnek ve hızlı. Rapor yazarlarının hepsi bu depolama tarzını desteklemiyor. NoSQL'in birçok örnek veritabanı uygulaması vardır. Şu anda en popüler gibi görünen MongoDB.

EAV - tanım Bu, tüm tabloyu veya yan tarafındaki bir bölümü (başka bir tabloda) çevirdiğiniz yerdir. Zaten kolayca uzaklaştıramayacağınız bir ilişkisel veritabanınız varsa, bu iyi bir seçimdir. Verdiğiniz özel bilgi tablosu örneği, bir EAV tablosunun iyi bir örneğidir.

XML sütunlarına sahip standart tablolar - Bunu, NoSQL'in ilişkisel tablolarla buluştuğu için düşünün. XML sütununda depolanan veriler, birden çok ilişkili alt veri dahil olmak üzere XML'in desteklediği herhangi bir biçim olabilir. "Normal" sütunlar olacağını bildiğiniz sütunlar için, verileri depolamak için uygun sütun türü olarak oluşturulabilirler (Soyadı, Adres, Şehir, Eyalet vb.).

Çok sayıda fazla sütunlu standart tablolar - İlişkisel bir veritabanınız var, XML veya EAV kullanamazsınız ve NoSQL bir seçenek değildir. Her türden çok sayıda fazladan sütun ekleyin. 30 veya daha fazla varchar, 30 veya daha fazla tam sayı, 15 veya daha fazla sayısal tahmin ediyorum. Ve bir değer için sütun kullandığınızda, yeniden kullanmayın . Ve sütunu da silmeyin .

Tüm bu çözümlerden, kendi düşüncem, NoSQL veya EAV yaklaşımını, kodunuzu ve şemanızı en az yeniden düzenleme ile en başarılı olarak bulacağınızdır.

Bir yıl değil, bir yıl veri topladığınız ve daha sonra tekrar topladığınız bir durumunuz olacaktır. Eski verilerin doğru bilgilerle güncellenmesini sağlamak sorunlu ve pahalıdır. Depolama da değildir.

Bu iki seçenekle ilgili sorunuzu yanıtlamak için ikisi de bana doğru gelmiyor. A) sizi kilitleyecek ve B) çok fazla iş. Açıkladığınız geçerli şema, bilgi tablosuna ("ad", "kare ayak" vb.) Bir arama tablosuna başvurulan kimlik yerine dize olarak çok kötü değil.

Ancak, bu bana bir NoSQL veritabanı için iyi bir aday gibi görünüyor ( http://en.wikipedia.org/wiki/NoSQL ). Bu tür bir veritabanıyla hiç çalışmamış olsam da, tarif ettiğiniz şey bunun çözdüğü tipik bir senaryodur.

Eşzamanlı özel sütun sayısı sonluysa ve sınırlar biliniyorsa (örneğin, String'ler için en fazla 10-20 Özel sütun, tamsayılar için x'ten fazla sütun vb.)
Temel tabloyu veri türü başına fazladan alanlarla kullanabilirsiniz ve bunun yerine her yıl tabloyu yeniden oluşturmak, yalnızca ilgili özel sütunları içeren ve genel alanları o yıl içindekileri yansıtacak şekilde yeniden adlandırarak o yıl için bir görünüm oluşturur.

House Table:
ID, Addr, City, State, Zip, custom_string1,cs_2,cs_3,custom_integer_1,ci_2,ci_3 ...

create view house_2014 as 
select ID, Addr, City, State, Zip,
custom_string1 as last_name,cs_2 as first_name ...

Bu yaklaşımdaki sorun, geçmişinizin olmaması, ancak sütun gereksinimlerini değiştirmeden önce her yıl kolayca bir kopya oluşturabilmenizdir.

create table house_2014_archive as select * from house_2014;
drop house_2014;
create view house_2015 as "select column list for new year";

Bu verileri saklamak istediğiniz tüm senaryoları sıralayabilir misiniz?

tabloya uygulanabilen sınırlı sayıda sütun birleşimi varsa, tüm senaryolara uygulanacak ortak sütunlarla bir "temel tablo" modellemeye çalışın, ardından daha fazla tablo oluşturun (bir tür miras uygulamak için; ERD ve veritabanı tasarımında alt tür / üst tür olarak bilinir.)

her senaryo için bir tablo, bu şekilde en azından tabloları temiz tutacak ve "soyadı" sütununda sokak adresi saklamaktan kaçınabileceksiniz ...

bu tasarım sorusuna bir göz atın: /programming/554522/something-like-inheritance-in-database-design