it-swarm.asia

أم لا لإنشاء جداول منفصلة لأنواع المنتجات المختلفة؟

أنا بصدد تصميم قاعدة بيانات ولديّ أفكار ثانية حول قرارات التصميم الأولية ...

أنواع المنتجات هي كما يلي ... النماذج والأجزاء ومجموعات خيارات الاستبدال والخيارات.

الخيار أ (التصميم الأول): لقد خططت لامتلاك جداول منفصلة لأنواع المنتجات المذكورة أعلاه. أود أن أقول أن 75٪ من الحقول ستكون متشابهة في كل جدول.

لقد أنشأت كل نوع منتج كجداول منفصلة بسبب الارتباطات التي أحتاج إلى إنشائها بينهما. على سبيل المثال ، يمكن أن يحتوي النموذج على العديد من الخيارات والخيار يمكن أن يحتوي على العديد من النماذج. يمكن أن يحتوي الخيار أيضًا على العديد من الأجزاء ويمكن أن يحتوي الجزء على العديد من الخيارات ... وهكذا.

الخيار ب: بدلاً من امتلاك جداول منفصلة ، يمكنني إنشاء جدول يسمى المنتج يشمل مجموعات وخيارات النموذج والجزء والجزء البديل. يمكن أن يكون لدي حقل واحد يسمى النوع للتمييز بين الطراز والخيارات وما إلى ذلك. أفترض أن الجانب السلبي هو عدم استخدام العديد من الحقول (اليسار فارغًا) لأنواع معينة من المنتجات. أعتقد أن هذا هو المكان الذي ستظهر فيه "أفضل الممارسات" ..

سيقلل الخيار B بشكل كبير من تعقيد تصميم ديسيبل. لن أضطر أيضًا للقلق بشأن الرجوع إلى مجموعة من الجداول عند سحب البيانات للاستعلامات ...

25
payling

إذا كان هذا هو قرار التصميم الخاص بي ، فمن المحتمل أن أختار المزيد من "الخيار C" (الخيار المعدل أ).

أولاً ، لماذا لا "الخيار ب":

لسبب واحد ، أنا أحب وضوح أن كل منتج لديه طاولته الخاصة. إذا كان كل جدول واحد كبير به حقل لتحديد النوع ، فإن العلاقة ليست واضحة.

من ناحية أخرى ، تتطلب استراتيجية الفهرسة دائمًا إدراج حقل النوع هذا. نظرًا لأنه 4 أنواع فقط ، فإن أصالة المؤشر منخفضة للغاية (SELECT * FROM product_table WHERE type='X' يقوم أساسا بمسح جدول كامل على أي حال)

الخيار ج

  • إنشاء جدول أصل يحتوي فقط على الأعمدة التي تشترك فيها جميع الأنواع
  • قم بإنشاء كل نوع منتج كجدول خاص به مع أعمدته الفردية ، مع واحد إضافي: ارتباط إلى الجدول الأصلي
  • قم بإنشاء كل جدول "ارتباط": Product_Option و Model_option وما إلى ذلك بروابط إلى المفاتيح المعنية.
  • بالنسبة لأولئك الذين لديهم روابط متبادلة (MODEL_OPTION ، OPTION_MODEL) ، يمكنك المضي قدمًا وإنشاء تلك الجداول أيضًا. سيضيف هذا وضوحًا في صلاتك لأي شخص ينظر إليها.

الجانب السلبي هو تعقيد التأكد من تجنب الأيتام عند تحديث/حذف الأشياء ، وتصميم الاستعلامات التي تستخدم هذه الجداول في البداية.

8
Derek Downey

أود أن أقترح أن تبدأ بالنموذج العلائقي "الصحيح" ، خيارك أ. إذا كان الاستخدام النموذجي لهذا النموذج يقودك نحو التشويه في بعض المناطق ، فلا تخف من القيام بذلك.

كنت أناقش مع أحد الزملاء الأسبوع الماضي كيف أن تصاميم المخططات غالبًا ما يتم اعتبارها شيئًا ثابتًا ولا يمكن أن تتغير أبدًا. من الغريب ، بالنظر إلى كيفية إعادة البناء في الممارسة المقبولة في كل طبقة أخرى من التطبيق ، أن إعادة هيكلة مخطط قاعدة البيانات لا تزال تعتبر غير عملية.

إذا كانت الواجهة إلى قاعدة البيانات مصممة بشكل جيد ، فلا يوجد شيء يمنعك من تكييف المخطط بينما تتعلم المزيد عن أنماط استخدام الأنظمة.

7
Mark Storey-Smith

يبدو هذا مشابهًا جدًا ل فواتير المواد/الكارالانات المتعددة الوراثة التي يصفها بول نيلسن في الفصل 17 من الكتاب المقدس لـ SQL Server 2008 .

إن الفصل بأكمله هو قراءة جيدة للغاية والقسم المحدد الذي يعالج مشكلتك الخاصة بالعديد من الأسئلة الموجودة على الصفحات 416-419.

هذه أفضل مناقشة رأيتها فيما يتعلق بنوع الأجزاء المنفجرة نوع تصميم البيانات.

2
Michael Riley - AKA Gunny

إذا كان بإمكانك تصوير سيناريو محتمل حيث ستكون هناك استفسارات متكررة تمر عبر جميع أنواع المنتجات الأربعة (والتي يبدو لي أنها محتملة) ، فإن الخيار B هو الأفضل.

بدلاً من ترك الكثير من الحقول غير الصالحة غير المستخدمة في جدول المنتج ، لماذا لا تضيف جدول ModelProduct ، وجدول PartProduct ، وجدول replacePartKitProduct ، ولديك فقط الحقول المميزة لهذه الأنواع في تلك الجداول؟ استخدم نفس المفتاح الأساسي على تلك الجداول مثل جدول المنتج الخاص بك. انضم إلى جدول المنتج و ModelProduct عندما تريد العمل مع النماذج. هل تحتاج إلى تحديد ما إذا كان سجل المنتج لديك جزءًا؟ ما عليك سوى الانضمام يسارًا من المنتج إلى PartProduct ، وإذا كان PartProduct. [PrimaryKey] ليس فارغًا ، فلديك جزء. إذا كانت فارغة ، فهي ليست جزءًا. بدلاً من ذلك ، يمكنك إضافة حقل ProductType إلى جدول المنتج.

0
Alan McBee