fazladan sütunlu tek tablo, şemayı yineleyen birden çok tabloya karşı

Bir noktada, veritabanında, her kaydın kullanmadığı birden çok sütun içeren tek bir tablo veya çoğaltılmış şema ile birden çok tablo olması gerekip gerekmediği konusunda bir karar vermem gereken bir proje üzerinde çalışıyorum.

Birden fazla sporla başa çıkabilen bir Spor bilgi uygulaması oluşturuyorum. Örneğin NBA, NHL, MLB, NFL ile başa çıkabiliriz. Her sporun çok benzer kavramları vardır - Takımlar, Tarifeler, Sakatlıklar, Oyuncu bilgisi ..

Tabii ki veri kaynağımız bize aynı şemadaki her veri parçasını vermiyor. Her sporun, tedarikçimizden veri aldığımız farklı bir Şeması vardır.

Ortaklıkları belirlemek için veri feed'lerini önceden analiz etmek için yeterli zaman (müşteri talepleri) olmadığından, bahsimi korudum ve 'güvenli bahis'i aldım ve her spor için tek bir masa seti yerine ayrı ayrı masalar yaptım. kullanılan sporlar.

Sonuç, tabloların çoğunda çoğaltılan şema ve böylece veritabanına çoğaltılan arabirimlerdir (örneğin, saklanan procs). NBA_Game, NFL_Game, NBA_Team, NFL_Team, vb gibi bir şey var .. her tablo diğerinin olmayan birkaç özellik olabilir ve paylaşılan birkaç olabilir. 4-5 spor arasında 5-10 masa için devam ediyor. Bunun tamamen kötü bir şey olup olmadığından hala emin değilim - alternatif, tüm sporların kullanamayacağı özelliklere sahip tek bir masa setine sahip olmak, kendi başına da hantal olabilirdi.

Bunu yapan herkes bu tür tasarımın tuzaklarına düştü ve deneyimlerini burada paylaşabilir mi? Yolda zor yolu öğrenmek yerine şimdi bilmeme yardımcı olabilecek şeyler var mı? Bunu, her kaydın kullanamayacağı sütunlarla birlikte büyük bir tablo / tablo kümesine sahip olarak mı yaptınız? Bunu yapmak için hangi tuzaklarla karşılaştın?

Geçmişte daha önce işe yarayan masa mirası gibi bazı alternatifler var mı ?

Teşekkürler

Nihayetinde, kullanım ve mimarlık geliyor.

Mimari

Sistem "herhangi bir sporu" ele alıyor mu? Mimari astronot şapkanızı takmanız ve bugün bile var olmayabilecek gelecekteki spor türlerini idare edebilecek jenerik bir sistem kurmanız fikri?

Öyleyse, dinamik olarak adlandırılmış tablolara sahip olmak büyük bir acıdır, bu nedenle gerekirse n sporu destekleyen bir şemaya sahip olmak mantıklı olacaktır.

Bununla birlikte, bu yaklaşıma karşı çok güçlü bir önyargım var: bu neredeyse her zaman daha fazla iştir ve daha kötü sonuçlara yol açar. Her bir spor için ayrı bir kullanıcı arayüzü, şema vb. Yapmak, sonuçta daha iyi bir kullanıcı deneyimine ve kodun sürdürülmesine yol açacaktır, bu da yüzeysel bir miktar çoğaltma anlamına gelse de (bunun nasıl önleneceği / en aza indirileceği ayrı bir sorudur).

Birden fazla spor yapan oyuncuları nasıl ele alırsınız? İki giriş alıyorlar mı (örneğin, farklı insanlar gibi davranıyorsunuz) veya onlarla belirli bir şey yapmaya mı çalışıyorsunuz?

kullanım

Bu nedenle, dinamik olarak spor yapmadığınızı varsayalım (örneğin, birisi yeni bir spor eklemek istiyorsa, onu eklemek için geliştirme çabası gerektirir).

Her seferinde birden fazla spor dalında oyuncuları (veya bahsettiğiniz herhangi bir nesneyi) sergilediğiniz bir zaman oldu mu?

Bunu, oyuncuya veya takım adına göre (spor ne olursa olsun) arayabileceğiniz bir arama işlevi için görebiliyordum, ancak bunun ötesinde birçok kullanım durumu hayal edemiyorum.

Bunu asla yapmanız gerekmiyorsa, yaklaşımınız gayet iyi. Burada okumayı bırakabilirsiniz.

Alternatif Şemalar

Görüntüleme

Ben KISS hayranıyım. 15 yılı aşkın yazılım geliştirmede, "işe yarayan en basit şeyi inşa et" felsefesine geri dönmeye devam ediyorum.

Bu yüzden ilk tepkim, bir çapraz spor arama işlevinin gerçekten tek kullanım durumu olduğunu varsayarsak, görünümler oluşturmaktır:

SELECT PlayerName, 'NFL' as [Sport], TeamName FROM NFL_Players JOIN NFL_Teams ... 
UNION  
SELECT PlayerName, 'NHL' as [Sport], TeamName FROM NHL_Players JOIN NHL_Teams ... 
UNION ....

Tabii ki, yeni bir spor eklerseniz, görünüme eklemeniz gerekir. Diğer yaygın bilgileri dahil etmek de yararlı olabilir, ancak bu gerçekten neyin gösterilmesi gerektiğine bağlıdır.

Arama kodu (yanında belki nasıl bağlantıya bilerek çok veya herhangi bir özel koduna sahip gerekmez yüzden, Görünüm tanımı tüm spor özgü şeyler tutmaya çalışacaktı /nhl/players/player-namevs /nfl/...uygulama bunu yapar ya da bununla birlikte).

Tablo Devralma

Tablo kalıtımı işe yarayabilir, ancak oldukça karmaşıktır. Bununla ilgili tonlarca deneyimim yok ve aslında, her değerlendirmede yer aldığımda, daha basit bir şey yaptığımızı düşünüyorum (burada önerdiğim gibi).

Kişisel olarak, bunun neden yararlı olacağını henüz bulmadım, ancak belki de karmaşıklığı haklı çıkaran ikna edici bir kullanım durumu var (bilmiyorum) (örneğin, Tablo mirası kullanım durumunu diğer çözümlerden daha iyi çözüyor) .

Spora özgü özellikler için ayrı tablolar

playersTüm sporların tüm oyuncuları için ortak özelliklere sahip tek bir masa ve ardından nhl_players_detailsbir playerId ve oyuncu hakkında ek bilgi içeren sütunlar içeren başka bir tablo kümesi yapabilirsiniz . Bir ton ortak özellik varsa veya "tüm sporlardan tüm oyuncular" ın birçok kullanımı varsa, bu mantıklı olabilir.

Spora özgü özellikler için anahtar / değer çiftleri

Tamamen alternatif bir yaklaşım: Bir var playersve sonra (ortak isim gibi özellikleri ile yine) tablo player_datavardır masaya PlayerId, Sport, Attribute, Value. Girilen özellik adları spora özel olacaktır. Bu, şemayı değiştirmeden temel olarak yeni özellikler eklemenize izin verir (kodunuzun elbette bunları yüklemeyi / görüntülemeyi bilmesi gerekir). Dezavantajı bazı bütünlüğü kaybetmektir: değer genellikle bir dize alanı olurdu, bu nedenle uygulama kodunuzun esnek olması ve dizeyi valuebelirli bir veri türüne (tamsayı gibi) dönüştüren olası hataları ele alması gerekir .

Bu konsept elbette Takımlar, Oyunlar vb. İçin geçerli olabilir.

Veritabanı normalleştirmesinden bahsediyorsunuz . Mükemmel bir veri modeli diye bir şey olmadığını ve daha normalleşmenin her zaman daha iyi olmadığını öğrenmek için rahatlayabilirsiniz. Normalizasyon, veri modelinin netliği ve veritabanı performansı açısından maliyet getirebilir. Bu nedenle, seçilecek en iyi model kullanım gereksinimlerinize bağlı olacaktır.

Yüzeyde, örnekleriniz kavramda yeterince benzer görünüyor (X_Game vs Y_Game ve X_Team vs Y_Team), birkaç sütunun ekstra yükünün mantıksız görünmediği. Bununla birlikte, her spor masaya birkaç düzine fazladan sütun ekleyecekse, gerçekten de hantal olurdu.

Bu durumda, ortak verilerin merkezi bir tabloda tutulduğu ancak spora özgü verilerin bağlantılı bir veri yapısında tutulduğu karma bir modeli düşünmek isteyebilirsiniz. Gibi bir şey:

table Game {
    gameId int,
    teamId1 int fk,
    teamId2 int fk
}

table HockeyGame {
    gameId int fk,
    penaltyMinutes int
}

table BasketballGame {
    gameId int fk,
    freeThrows int
}