Tablo tasarımında pek fazla tecrübem yok. Amacım gereksinimleri karşılayan veya daha fazla ürün tablo altında oluşturmak için:

• Ürünleri (TV, Telefon, PC,...) destekler. Ürünün her türlü farklı parametre vardır, gibi:

  • Telefon Rengi, Boy, Kilo, OS olacak...

  • PC CPU, sabit disk, RAM var

• Parametreleri ayarlamak dinamik olmalı. Ya da sizin gibi herhangi bir parametre ekleyebilirsiniz.

Nasıl her Ürün için ayrı bir tablo olmadan bu ihtiyacını karşılayabilir miyim?

Tarif: modelleme için en azından bu beş seçeneğiniz var

• Single Table Inheritance: tüm Ürün türleri için bir tablo, her türlü tüm öznitelikleri depolamak için yeterli sütunlar ile. Bu anlamına gelirbir sürüherhangi bir satırın üzerine BOŞ en sütun,.

• Class Table Inheritance: Ürünler, depolama öznitelikleri tüm ürün türleri için ortak bir tablo. Ürün tipine göre daha sonra bir tablo, depolama, ürün türüne özgü nitelikleri.

• Concrete Table Inheritance: ortak Ürün öznitelikleri tablo. Bunun yerine, ürün tipi başına bir tablo, her iki ortak ürün öznitelikleri depolamak ve ürüne özgü nitelikleri.

• Serialized LOB: Ürünler, depolama öznitelikleri tüm ürün türleri için ortak Bir tablo. Ekstra bir sütun yarı yapılandırılmış bir veri BLOB, XML, YAML, JSON, veya başka bir formatta depolar. Bu BLOB her bir ürün tipi için özel öznitelikleri depolamak için izin verir. Fantezi Tasarım Desenleri bu tarif için, Cephe ve Hatıra olarak kullanabilirsiniz. Ama ne olursa olsun SQL içinde kolaylıkla sorgulanabilir davranışlara bir damla var; tüm damla uygulamasına geri getir ve onu dışarı sıralamak gerekir.

• Entity-Attribute-Value: Ürün için Bir tablo, satır ve niteliklerini döner bir tablo, sütun yerine. Etkin değeri ilişkisel paradigma açısından geçerli bir tasarım değil, ama birçok kişi öyle bir şeye girişmedim. Bu "Özellikleri Desen" başka bir cevap söz. Tuzaklar bazıları için StackOverflow üzerinde eav tag Diğer sorular.

Bir sunum, Extensible Data Modeling bu konuda daha yazdım.

Birçok kişi etkin değeri iyilik gibi görünse de, bilmiyorum. ek düşünceler hakkında etkin değeri: En esnek çözüm gibi, ve bu nedenle en iyisi gibi görünüyor. Ancak, akılda 9 ** atasözü tutun. Burada etkin değeri dezavantajları:

• Bir sütun zorunlu yapmak için bir yol (NOT NULL eşdeğer).
• Hiçbir şekilde girişlerini doğrulamak için SQL veri türleri kullanın.
• Öznitelik adları sağlamak için bir yolu sürekli olarak yazılmış.
• Hiçbir şekilde herhangi bir öznitelik, örneğin, bir arama tablosu için değerleri üzerine yabancı bir anahtar koymak.
• Geleneksel sekmeli bir düzen içinde sonuçlar alınıyor birden fazla satır öznitelikleri almak için her öznitelik için JOIN yapmanız gereken, çünkü karmaşık ve pahalıdır.

Esneklik etkin değeri derecesi daha geleneksel bir şekilde orijinal sorunu çözmek için olurdu dışındaki alanlarda kurban, muhtemelen kod olarak kompleks yapma gerektirir (veya daha kötüsü) verir.

Ve çoğu durumda, esneklik derecesine sahip olmak gereksiz. OPERASYON bu soru hakkında ürün çeşitleri, çok daha basit bir tablo oluşturmak için başına ürün tipi için ürüne özgü nitelikleri var bu yüzden biraz tutarlı yapısı zorunlu en az girişlerin aynı ürün tipi.

Yalnızca etkin değeri kullanmak istiyorumher satırpotansiyel niteliklerini farklı bir ayarlamak için izin verilmelidir. Ürün çeşitleri sınırlı ayarladığınızda, etkin değeri abartılı olur. Sınıf Tablo Devralma ilk tercihim olurdu.