تصميم المناقشة:ما هي طرق جيدة لتخزين ومعالجة إصدار الكائنات ؟ [مغلقة]

Question

أنا عمدا ترك هذا غامضة جدا في البداية.أنا أبحث عن مناقشة ما هي القضايا الهامة أكثر من أنا أبحث عن الأجوبة الصعبة.

أنا في منتصف تصميم التطبيق الذي لا يفعل شيئا مثل إدارة المحافظ.تصميم لدي حتى الآن

• المشكلة:مشكلة تحتاج إلى حل
• الحل:الحل المقترح إلى واحد أو أكثر من المشاكل
• العلاقة:علاقة بين اثنين مشاكل حلول ، أو مشكلة و حل.كسر مزيد من أسفل إلى:
  • الأم-الطفل - نوعا من التصنيف / شجرة التسلسل الهرمي
  • التداخل - درجة حلين أو مشكلتين حقا عنوان نفس المفهوم
  • عناوين - درجة مشكلة عناوين الحل

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

إذن السؤال:ما هو أفضل تصميم الإصدارات من هذه الأشياء حتى أتمكن من الحصول على حد سواء الحالية منظور تاريخي من أعمالي ؟

في وقت لاحق:ربما علي جعل هذا أكثر سؤال محدد ، على الرغم @إريك اللحية الجواب هو يستحق ما يصل.

لقد نظرت في ثلاثة البيانات والنماذج.سوف يكفي من كل لإظهار عيوب.سؤالي هو:وهو اختيار ، أو يمكنك التفكير في شيء أفضل ؟

1:مشاكل (و بشكل منفصل ، الحلول) هي المرجعي الذاتي في الإصدارات.

table problems
  int id | string name | text description | datetime created_at | int previous_version_id

  foreign key previous_version_id -> problems.id

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

2:إنشاء علاقة جديدة من نوع:الإصدار.

table problems
  int id | string name | text description | datetime created_at

هذا ببساطة يتحرك العلاقة من مشاكل وحلول الجداول في العلاقات الجدول.الازدواجية نفسها مشكلة ، ولكن ربما قليلا "نظافة" منذ أن كنت بالفعل مجردا مفهوم العلاقة.

3:استخدام المزيد من التخريب-مثل هيكل ؛ نقل كافة المشكلة والحل الصفات في جدول منفصل نسخة منها.

table problems
  int id

table attributes
  int id | int thing_id | string thing_type | string name | string value | datetime created_at | int previous_version_id

  foreign key (thing_id, thing_type) -> problems.id or solutions.id
  foreign key previous_version_id -> attributes.id

وهذا يعني أن لتحميل النسخة الحالية من مشكلة أو حل علي جلب كافة الإصدارات من السمة ، فرزها حسب التاريخ ومن ثم استخدام معظم الحالية.التي قد لا تكون رهيبة.ما يبدو سيئة حقا بالنسبة لي هو أنني لا أستطيع نوع-تحقق هذه الصفات في قاعدة البيانات.أن value العمود يجب أن تكون خالية من النص.أنا يمكن أن تجعل من name عمود إشارة إلى منفصل attribute_names جدول يحتوي على type عمود, ولكن هذا لا القوة النوع الصحيح في attributes الجدول.

في وقت لاحق لا يزال:استجابة @إريك اللحية تعليقات حول طاولة متعددة المفاتيح الخارجية:

للأسف ما عندي وصف هو التبسيط:هناك نوعان من الأشياء (المشاكل والحلول).في الحقيقة لدي حوالي 9 أو 10 أنواع مختلفة من الأشياء, لذا يجب أن يكون 9 أو 10 أعمدة المفاتيح الخارجية في إطار الاستراتيجية الخاصة بك.أردت أن استخدام واحد الجدول الميراث ، ولكن الأمور القليل جدا من القواسم المشتركة التي سيكون للغاية الإسراف فعله الجمع بينهما في جدول واحد.

Answer 1

هممم يبدو مثل هذا الموقع...

بقدر ما تصميم قاعدة البيانات سوف تذهب ، إصدارات نظام مثل إس, حيث أنك لا تفعل في الواقع أي تحديثات فقط إدراج (مع رقم الإصدار) عندما تتغير الامور قد يكون ما تحتاجه.وهذا ما يسمى MVCC متعددة القيمة التزامن التحكم.ويكي هو آخر مثال جيد على ذلك.

Answer 2

@غايوس

foreign key (thing_id, thing_type) -> problems.id or solutions.id

كن حذرا مع هذه الأنواع من "متعدد الاتجاهات" مفاتيح خارجية.وقد أظهرت تجربتي أن أداء الاستعلام تعاني بشكل كبير عند الانضمام الشرط قد تحقق نوع قبل معرفة الجدول الذي للانضمام إلى على.أنها لا تبدو أنيقة ولكن nullable

problem_id and solution_id 

سوف تعمل على نحو أفضل بكثير.

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

Answer 3

كيف رأيك في هذا:

الجدول مشاكل
int id | string name | وصف النص | datetime created_at

الجدول problems_revisions
الباحث مراجعة | int id | string name | وصف النص | datetime created_at
الخارجية key id -> المشاكل.معرف

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

1. كفاءة الوصول إلى الإصدار الحالي - تحديد المشاكل كالعادة
2. مخطط بديهية و قريبة من الواقع الذي تريد نموذج
3. ينضم بين الجداول في مخطط الحفاظ على كفاءة
4. باستخدام رقم المراجعة في بوسنس الصفقة يمكنك أن تفعل الإصدارات أكثر من سجلات الجدول مثل إس يفعل أكثر من الملفات.

Answer 4

أعتقد أن هناك

الخيار 4:الهجين

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

إذا description وغيرها من الحقول الكبيرة في البقاء في الأشياء ، على الرغم من أنه كما لا يحل الازدواجية في الفضاء المشكلة.

table things
  int id | int type | string name | text description | datetime created_at | other common fields...
  foreign key type -> thing_types.id

table custom_attributes
  int id | int thing_id | string name | string value
  foreign key thing_id -> things.id

Answer 5

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

كنت قد جداول مشكلة, حل, والعلاقة التي تمثل الوضع الحالي.وسيكون هناك أيضا problem_history, solution_history, ، وما إلى ذلك الجدول.هذه سيكون الطفل الجداول من المشكلة ولكن أيضا تحتوي على أعمدة إضافية VersionNumber و EffectiveDate.سيكون مفتاح (ProblemId, VersionNumber).

عند تحديث مشكلة ، سوف أكتب القيم القديمة في problem_history الجدول.نقطة في الوقت الاستفسارات وبالتالي ممكن كما يمكنك انتقاء problem_history سجل صحيحة-في تاريخ معين.

حيث كنت قد فعلت هذا من قبل, أنا خلقت أيضا عرض الاتحاد problem و problem_history وهذا في بعض الأحيان مفيدة في مختلف الاستفسارات.

الخيار 1 يجعل من الصعب على الاستعلام عن الوضع الحالي ، كما كل ما تبذلونه من البيانات التاريخية هو مختلطة مع البيانات الحالية الخاصة بك.

الخيار 3 ستكون سيئة على أداء الاستعلام وسيئة ضد رمز كما عليك أن تكون الحصول على الكثير من الصفوف لما ينبغي أن يكون مجرد استعلام بسيط.