Farklı ürün tipleri için ayrı tablolar yaratılıp yaratılmayacağı?

25

Veri tabanı tasarlama sürecindeyim ve ilk tasarım kararlarım hakkında ikinci düşüncelerim var ...

Ürün çeşitleri aşağıdaki gibidir ... Modeller, parçalar, yedek parça kitleri ve seçenekler.

A Seçeneği (ilk tasarım): Yukarıdaki ürün tipleri için ayrı masalara sahip olmayı planladım. Alanların yaklaşık% 75'inin her tabloda aynı olacağını söyleyebilirim.

Her ürün tipini, aralarında oluşturmam gereken dernekler nedeniyle ayrı tablolar olarak yarattım. Örneğin, bir Model birçok seçeneğe sahip olabilir ve bir seçenek birçok modellere sahip olabilir. Bir seçenek ayrıca birçok parçaya sahip olabilir ve bir parça birçok seçeneklere sahip olabilir ...

Seçenek B: Ayrı masalara sahip olmak yerine, model, parça, yedek parça kitleri ve seçenekleri içeren Ürün adında bir masa oluşturabilirim. Model, seçenekler vb. Arasında ayrım yapmak için tür olarak adlandırılan bir alan olabilirdi. Sanırım aşağı taraf, bazı ürün türleri için hiçbir zaman boş bırakılmayacak (boş bırakılmış). Sanırım bu, "en iyi uygulamaların" devreye gireceği yer.

Seçenek B, db tasarımının karmaşıklığını büyük ölçüde azaltır. Ayrıca sorgular için veri toplarken bir grup tabloya başvurma konusunda endişelenmeme gerek kalmadı ...

database-design database-recommendation

— payling
kaynak

2

Bu noktada, tablo düzeninizi taklit eden ve bunları verilerle dolduran elektronik tablolar oluşturmanızı öneririm. Bu, olabilecek zayıflıkları ortaya çıkaracaktır.

— Michael Riley - AKA Gunny

Farklı anahtarlarda farklı tablolarda bulunan yabancı anahtarları nasıl işaret edeceksiniz? Lütfen masa mirasına bakınız.

— Neil McGuigan,

8

Bu benim tasarım kararım olsaydı, muhtemelen daha fazla bir 'Seçenek C' (değiştirilmiş seçenek a) ile giderdim.

İlk olarak, neden 'B Seçeneği' olmasın:

Birincisi, her ürünün kendi masasının sahip olduğu netliği seviyorum. Türü belirlemek için bir alana sahip büyük bir tablo varsa, ilişki net değildir.

Birincisi, indeksleme stratejisi her zaman bu tip alanın listelenmesini gerektirecektir. Sadece 4 tip olduğundan, indeks kardinalitesi son derece düşüktür ( SELECT * FROM product_table WHERE type='X'temelde zaten tam masa taraması yapıyor)

Seçenek c

Yalnızca tüm türlerin paylaştığı sütunları tutan bir üst tablo oluşturun.
Her ürün türünü kendi sütunları ile kendi sütunlarıyla oluşturun, bir ekstra ile: Üst tabloya bir bağlantı
Her 'link' tablosunu oluşturun: İlgili tuşlara bağlantılar içeren Product_Option, Model_option, vb.
Karşılıklı bağlantılar (MODEL_OPTION, OPTION_MODEL) olanlar için devam edin ve bu tabloları da oluşturun. Bu, arayan herkes için katılımlarınıza netlik kazandıracak.

Dezavantajı ise, işler güncellendiğinde / silindiğinde yetimlerden kaçınmanın sağlanması ve başlangıçta bu tabloları kullanan sorgular tasarlamanın karmaşıklığıdır.

— Derek Downey
kaynak

5

Şimdilik sadece 4 tip var, fakat daha sonra eklenirse ne olacak? Amazon'un ana ürün tablosunun asıl adı "Kitaplar" olduğundan eminim, ancak şimdi her ürün türü için ayrı bir masaları var mı? Her türün kendi tablosu olması gerektiğini sanmıyorum, ancak her türün ortak olabileceği ek özellikler için bir EAV modeli kullanabilirsiniz.

— Aaron Bertrand

1

@Aaron Fuar, ürün çeşitlerinin gelecekteki artmasıyla ilgili. Bu senaryo makul bir şekilde 10'dan fazla ürün çeşidine genişletilebilseydi yeniden düşünürdüm. Ancak, belirli ürün tablolarının az miktarda ürün türü için adil bir tasarım seçeneği olduğunu düşünüyorum.

— Derek Downey,

1

Seçenek C: Bir bağlantı masasına sahip olmak gerekli mi? Product_Option PK’nın Ürün tablosunun PK’siyle eşleşeceğini ve her iki tabloyu birbirine bağlamak için bir ilişki yaratacağını hayal ediyorum.

— ödeme yapma

Örnek olarak Product_option kullanıldığında, şema şöyle olur (aklımda): id, productID, optionID. productIDbir FK olacak product.idve optionIDbir FK olacak option.id. Bağlantı tablosu ile kastettiğim buydu. Ve evet, bu tasarımda tek bir ürünün birden fazla seçeneğe bağlanmasına izin vermek gerekir.

— Derek Downey

Tamam anlıyorum. Yazdıklarını yanlış okudum .. Hata!

— 13'te ödeme

7

"Doğru" ilişkisel model, yani A seçeneğinizle başlamanızı öneririm. Bu modelin tipik kullanımı sizi bazı alanlarda denormalize etmeye yönlendirirse, bunu yapmaktan korkmayın.

Geçen hafta bir meslektaşımla şema tasarımlarının genellikle taştan yapılmış ve hiç değişmeyen bir şey olarak değerlendirildiğini tartışıyordum. Bir uygulamanın diğer tüm katmanlarında yeniden yapılanmanın kabul edilen uygulamada olduğu göz önüne alındığında garip, bir veritabanı şemasının yeniden yapılandırılmasının hala pratik olmadığı görülmektedir.

Veritabanının arayüzü iyi tasarlanmışsa, sistem kullanım düzenleri hakkında daha fazla bilgi edindikçe şemayı uyarlamanızı engelleyen hiçbir şey yoktur.

— Mark Storey-Smith
kaynak

2

Çok benzer Bu sesler malzemeleri / çoklu kardinallikleri Senetlerine Paul Neilsen içinde açıklanan heirarcy Bölüm 17 arasında SQL Server 2008 İncil'de .

Bölümün tamamı çok iyi bir okuma ve çoktan çok sayıdaki konunuzu ele alan belirli bir bölüm 416-419. Sayfalarda bulunmaktadır.

Bu, patlatılan parçaların veri tasarımı türüyle ilgili gördüğüm en iyi tartışma .

— Michael Riley - AKA Gunny
kaynak

Bu çözüm B seçeneğine benziyor (doğru anlıyorsam, ki emin değilim). Modeller, seçenekler, kitler vs. arasındaki ilişkileri oluşturmak için bir ana masaya (Ürünler) ve bir "bağlantı" masasına (aka bitişik masa / BillsofMaterials) sahip olurdum. Bu doğru mu?

— 18’de ödeme yapma

Sanırım sorun seçenekler yüzünden bulanık. Tartışmanın dışındaki seçenekleri bir anlığına kaldıralım. Parçalar en küçük birimdir. Bir grup parça bir model oluşturur. Bir kit biçimindeki bir grup yedek parça, modelin bir alt kümesini oluşturur. Çok uzak çok iyi. Artık parça seçeneklerine sahip olmanız için basitlik varsayımına izin verelim, bu iki kategori rengini (siyah, kırmızı, krom) ve malzemeyi (metal, ahşap, plastik) kapsar. Ayrıca modellerin seçeneklerinin olduğunu da söyledin. Model seçeneklerinin parça seçeneklerinden ayrı mı yoksa parçaların modelleri farklı kılmasından dolayı modellerin yalnızca seçenekleri var mı?

— Michael Riley - AKA Gunny,

Tasarımımda parçaların "seçenekleri" yok. Seçeneği, genişletilmiş işlevsellik sağlayan bir modelde devam eden bir şey olarak tanımlarım. Bir seçenek parçalardan oluşur. Bir model birçok farklı seçeneğe sahip olabilir. Bir seçenek, birçok farklı modele de uyar.

— ödeme

Sorunu böyle ifade etmedin. Alıntı: "Örneğin, bir Model birçok seçeneğe sahip olabilir ve bir seçenek birçok modellere sahip olabilir. Bir seçenek aynı zamanda birçok parçaya sahip olabilir ve bir bölüm birçok seçeneğe sahip olabilir ... vb." Tablo düzeninizi taklit eden elektronik tablolar oluşturun ve bunları verilerle doldurun. Bu, olabilecek zayıflıkları ortaya çıkaracaktır.

— Michael Riley - AKA Gunny

0

Dört ürün türünün hepsinde de sıkça sorulan soruların olduğu muhtemel bir senaryoyu görüntüleyebiliyorsanız (ve bu muhtemelen bana görünebilir), B seçeneğiniz en iyisidir.

Ürün tablosunda çok sayıda kullanılmayan boş alan bırakmak yerine, neden bir ModelProduct tablosu, bir PartProduct tablosu, bir SparePartKitProduct tablosu eklemiyorsunuz ve sadece bu tablolarda bu türler için farklı alanlar var? Bu tablolarda aynı birincil anahtarı Ürün tablonuzla kullanın. Modellerle çalışmak istediğinizde Ürün ve ModelProduct tablosuna katılın. Sahip olduğunuz Ürün kaydının bir Parçası olup olmadığını belirlemeniz mi gerekiyor? Yalnızca Product'den PartProduct'a bir sol birleştirme yapın ve PartProduct. [PrimaryKey] boş değilse, bir Partiniz olur. Eğer boş ise, bir Parça değildir. Alternatif olarak, Ürün tablosuna bir ProductType alanı ekleyebilirsiniz.

— Alan McBee
kaynak

Boş alanlar çok az olacaktır, çünkü alanların kabaca% 75'i her masada kullanılacaktır. Sanırım ürün tipleri arasındaki ilişkiler hakkında daha çok endişeliyim. Aynı tabloya işaret eden üç ya da öylesine bağlantı tabloları var. Model_has_Option İki tür anahtar, her ikisi de ürün tablosunun ürün kimliği, eğer ürün türlerini temsil etmek için sadece bir tablo kullanacak olsaydım. Yapılması veya yapılmaması gereken doğru şey ise daha çok endişeleniyorum.

— ödeme yapma

“Doğru” kararı etkileyen birçok faktör olmasına rağmen, dikkate alınması gereken iki geniş faktör vardır. 1: genel performans gereksinimleri; 2: uyarlanabilirlik / karmaşıklık / bakım kolaylığı. Bu ikisinden biri muhtemelen diğerinden biraz daha önemlidir. Hıza ihtiyacınız varsa, Seçenek A'ya yapıştırarak denormalize edin. Beklenen bu. Düzenli olarak şemaya girmeniz gerekiyorsa ve hız en önemli faktör değilse, Seçenek B'dir. Seçeneklerinizi “başkalarının en iyi uygulamalarına” bağlı kalarak değil, önceliklerinizi bilerek “doğru” olarak elde edersiniz.

— Alan McBee,