كيفية التغلب على أوجه القصور في الإبلاغ عن EAV قاعدة البيانات ؟

Question

أوجه القصور الرئيسية مع الكيان قيمة السمة قاعدة البيانات التصاميم في SQL كل شيء يبدو أن تكون ذات صلة إلى التمكن من استعلام تقرير عن البيانات بكفاءة وبسرعة.معظم المعلومات قرأت على الموضوع يحذرون من تنفيذ EAV بسبب هذه المشاكل المشتركة من الاستعلام/الإبلاغ عن جميع التطبيقات تقريبا.

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

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

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

لا المسائل مع EAV نظم معظمها يذهب بعيدا إذا كان لديك منفصلة الإبلاغ عن بيانات الاستعلام?

تحرير:شكرا على التعليقات حتى الآن.واحدة من الأمور الهامة حول النظام أنا أعمل على ذلك أنا حقا فقط نتحدث عن استخدام EAV واحدة من الكيانات ليس كل شيء في النظام.

كله جوهر هذا النظام هو أن تكون قادرة على سحب البيانات من عدة مصادر غير معروفة في وقت مبكر وأزمة البيانات إلى الخروج مع بعض "المعروفة" بيانات عن كيان معين.لذلك كل "الميدان" أنا أتعامل مع متعدد الكرام و أنا أيضا أن مسار التاريخ لكل منها.تطبيع تصميم هذا ينتهي 1 الجدول في الحقل الذي يجعل الاستعلام عن هذا النوع من المؤلم على أي حال.

وهنا الجدول مخططات وبيانات العينة أنا أبحث في (تغير واضح من ما أعمل عليه ولكن أعتقد أنه يوضح هذه النقطة جيدا):

EAV الجداول

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field       - Value         - EffectiveDate -
-------------------------------------------------------------------
-      123 -    CIA - HomeAddress - 123 Cherry Ln -    2010-03-26 -
-      123 -    DMV - HomeAddress - 561 Stoney Rd -    2010-02-15 -
-      123 -    FBI - HomeAddress - 676 Lancas Dr -    2010-03-01 -
-------------------------------------------------------------------

الإبلاغ الجدول

Person_Denormalized
----------------------------------------------------------------------------------------
-  Id - Name      - HomeAddress   - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
----------------------------------------------------------------------------------------
- 123 - Joe Smith - 123 Cherry Ln -                  0.713 -                2010-03-26 -
----------------------------------------------------------------------------------------

تطبيع التصميم

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_HomeAddress
------------------------------------------------------
- PersonId - Source - Value         - Effective Date - 
------------------------------------------------------
-      123 -    CIA - 123 Cherry Ln -     2010-03-26 -
-      123 -    DMV - 561 Stoney Rd -     2010-02-15 -
-      123 -    FBI - 676 Lancas Dr -     2010-03-01 -
------------------------------------------------------

"الثقة" مجال هنا يتم إنشاؤها باستخدام المنطق التي لا يمكن التعبير عنها بسهولة (على كل) باستخدام SQL حتى بلدي العملية الأكثر شيوعا إلى جانب إدخال قيم جديدة سيتم سحب جميع البيانات عن الشخص كل المجالات لذلك أنا يمكن أن تولد سجل التقارير الجدول.هذا هو في الواقع أسهل في EAV نموذج ما يمكنني فعله استعلام واحد.في تطبيع تصميم, أنا في نهاية المطاف الحاجة إلى القيام 1 الاستعلام في مجال لتجنب ضخمة الديكارتي المنتج من الانضمام لهم جميعا معا.

Answer 1

إجابة قصيرة - نعم ، قاعدة بيانات الإبلاغ هي نهج معقول لحل مشاكل الإبلاغ من نموذج بيانات EAV.

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

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

Answer 2

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

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

في الواقع, تعال إلى التفكير في الأمر:"النظام الذي يتيح للمستخدمين تخزين أي نوع من البيانات على الإطلاق" هو ما يعادل نظام يسمح للمستخدمين فقط تحديد relvars.ولكن ما هي جزء من هذا النظام يسمح للمستخدمين لتحديد القيود على كل سمة?عفوا ، EAV الحشد يبدو أنه قد غاب غير مهم من جوانب إدارة البيانات ، على ما يبدو...

Answer 3

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

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

حظا جيدا في ذلك.

Answer 4

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

إذا كنت تقوم ببناء EAV DB تقضي الكثير من الوقت في تصميمه ، فسيقوم التصميم إما بتقديم أو يكسر طلبك وسيكون كابوسًا يحاول إصلاح أو التعامل مع واحد سيئ التصميم.