كيفية منع الاستعلامات العودية العميقة مع كيانات تتكون من كيانات من نفس النوع؟ [مثال رائع في الداخل

Question

لا تقلق! يبدو أكثر تعقيدًا مما هو عليه في الواقع! فقط النزول إلى المشروبات!

Tldr-version: كيفية الاستعلام عن الكيانات وتحديثها بكفاءة علاقات مع كيانات أخرى؟

فيما يلي سيناريو للاهتمام في نمذجة البيانات مع جدولين كانا يحيرونني:

Entities { ID, Name, ScalarValue }

ComponentEntities { AggregateEntityID, ComponentEntityID, quantity }

AggregateEntityID و ComponentEntityID هي مفاتيح أجنبية ل Entities الطاولة.

أعطني المثال الدموي بالفعل

Drinks { ID, Name, Alcohol% }

DrinkIngredients { CocktailID, IngredientID, amount }

Drinks { 1, "Vodka", 40% }
Drinks { 2, "Tomato juice", 0% }
Drinks { 3, "Tabasco", 0% }
Drinks { 4, "Bloody mary", - }

DrinkIngredients { 4, 1, 0.2 } // Bloody mary has 0.2*Vodka
DrinkIngredients { 4, 2, 0.7 } // Bloody mary has 0.7*Tomato juice
DrinkIngredients { 4, 3, 0.1 } // Bloody mary has 0.1*Tabasco

إذا أردنا الحصول على محتويات ماري الدموية ، فسنفعل ذلك SELECT * FROM DrinkIngredients WHERE CocktailID == 4.

معيار جميل لا شيء غريب هناك. تحب ليزا أن تجعلها أحلى قليلاً عن طريق إضافة بعض العاطفة إليها:

Drinks { 6, "Passion", 13% }
Drinks { 7, "Bloody Mary Pink", - }

DrinkIngredients { 7, 4, 0.8 }  // Bloody Mary Pink has 0.8*Bloody Mary
DrinkIngredients { 7, 6, 0.2 }  // Bloody Mary Pink has 0.2*Passion

كانت أم ليزا تتذوقها لفترة طويلة لدرجة أنها تعتقد أنها وجدت المزيج النهائي بين الاثنين:

Drinks { 8, "Bloody Milf", - }
DrinkIngredients { 8, 4, 0.45 } // Bloody Milf has 0.45*Bloody Mary
DrinkIngredients { 8, 7, 0.55 } // Bloody Milf has 0.55*Bloody Mary Pink

أضف زوجين أكثر من هؤلاء يتكون من المستويات ولدينا عودية علائقية عميقة. التقييد الوحيد هو أن الكيان لا يمكن أن يتكون من نفسه.

يبدو أن هذا يشكل أ إخراج الرسم البياني الحشيش.

RDBMS: تتمثل إحدى طرق "ذاكرة التخزين المؤقت" في حساب البيانات ذات الصلة وتخزينها في الكيان نفسه (أو ربما في جدول آخر). في المثال أعلاه ، كان محتوى الكحول لماري الدموية يحسب مرة واحدة عندما يتم إنشاؤه وتخزينه في مجال ٪ الكحول. في هذه الحالة ، تصبح التحديثات باهظة الثمن لأننا يتعين علينا تحديث كل مشروب (إلى جانب التسلسل الهرمي للاعتماد بأكمله) الذي يتكون من المشروع المحدث.

أسئلة

RDBMS: هل هناك طريقة أفضل للوصول إلى قيم الأوراق (المشروبات التي لا تتكون من تلك الأخرى) من الحصول على مشروب "الوالد" حتى يتم الوصول إلى مشروب الأوراق؟

كلاهما ، RDBMS و NOSQL ، لديهم مشكلة في هذا: بطريقة أو بأخرى.

الخلاصة القاع: هل هذا عملي وعملي؟

ما أحتاجه هو مفهوم مضاد

Answer 1

"RDBMS: هل هناك طريقة أفضل للوصول إلى قيم الأوراق (المشروبات التي لا تتكون من تلك الأخرى) من الحصول على مشروب" الوالد "حتى يتم الوصول إلى مشروب الأوراق؟"

لا أفهم هذا. المشروبات التي لا تتألف من الآخرين لا علاقة لها بالكروية. إنها بسيطة باستثناء أو في مكان عدم وجودها.

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

كلاهما ، RDBMS و NOSQL ، لديهم مشكلة في هذا: بطريقة أو بأخرى.

RDBMS ليس لديهم بالفعل مشكلة في هذا. تم تحديد المشكلة بالفعل قبل بضعة عقود (الثمانينيات أو نحو ذلك) ، وتم معالجتها عن طريق تعديل الجبر العلائقي مع عملية إغلاق متعدية ، ونسخة معممة منه. يدعم SQL هذا من خلال الاستعلامات المتكررة ، وكما قال فرانك ، على الأقل جميع الكلاب الكبيرة تدعم جميع الاستعلامات العودية بطريقة أو بأخرى.

الخلاصة القاع: هل هذا عملي ومجدنا؟ "

إن كتابة الاستفسارات العودية ليست تافهة تمامًا إذا لم تقم بذلك من قبل. هل هذا يجعلها "غير عملية"؟ لا أعرف.

Answer 2

العديد من RDMSS تدعم الاستعلامات العودية. انظر على سبيل المثال http://msdn.microsoft.com/en-us/library/ms186243.aspx.