لماذا لم تكن قواعد البيانات الموجهة للكائنات ناجحة (حتى الآن)؟[مغلق]
https://stackoverflow.com/questions/170649
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
هذا هو السؤال.أعط سببًا واحدًا فقط يجعلك تعتقد لماذا فشل OODB أو لماذا لا تزال العديد من الأنظمة في الوقت الحاضر تستخدم قواعد البيانات العلائقية.
المحلول
هل يمكننا الإجابة أكثر من مرة؟ وهناك سبب آخر هو أن العلائقية في DB لها أساس قوي في الرياضيات: من تعريف العلاقة، من خلال الحق في الأشكال العادية، والنظرية هي الصخور الصلبة. صحيح أن النموذج العلائقي لا يعين جيدا لOO، ولكن IMHO فوائد واستقرار هذا النموذج تفوق مشكلة رسم الخرائط.
نصائح أخرى
والسبب الرئيسي هو SQL. ومن المفيد جدا أن تكون قادرة على استخدام البيانات من قاعدة بيانات في سياقات أخرى خارج التطبيق، وغالبا مع موضوع قواعد البيانات يتم تخزين البيانات في شكل لا يمكن بسهولة الاستعلام عنها. مع قاعدة بيانات علائقية يمكن للبيانات أن تصبح جزءا من مستودع البيانات، على سبيل المثال، أو الاستعلام فقط عن طريق مدراء تميز الكلية الخ.
وأعتقد أنه لأن "قواعد بيانات الكائن" يقومون بحل مشكلة (تقريبا) لا أحد لديه حقا. لاستمرار بسيط من الرسوم البيانية وجوه، والتسلسل في صلب معظم البيئات OO هو "جيدة بما فيه الكفاية". إذا كنت ترغب في القيام بعمليات متطورة على مجموعة فرعية من البيانات الخاصة بك، ثم قاعدة بيانات علائقية وSQL هي تتطابق تماما.
وبخلاف بعض التطبيقات الهامشية (الرسوم البيانية الكائن الهائلة التي لا يمكن أن تبقى في الذاكرة، ولكن الذي العلاقات لا تبسط بشكل جيد لاستخدام RDBMS)، وهناك في الحقيقة ليست أي حاجة لهذه الأدوات.
وفقط لأن OODB ليست هي السائدة لا يزال يتعين علينا النظر في النجاحات التي كان لها. وكلاهما يستخدم ذاكرة التخزين المؤقت وZope على نطاق واسع (نسبيا) ولكن سيتم النظر الناجحة التي قام بها بعض المعايير.
ولعل السبب الأكبر أن OODB لم ترسخ بشكل كبير هو بسبب نجاح النظم بين وجوه العلائقية الهجين التي تأخذ أكثر من حصتها السوقية المحتملة من OODB: كيو وينفورميكس
وأنا أعلم أن هذا لا يجيب مباشرة على السؤال ولكن هو، كما أعتقد، جزءا من المعادلة. وعموما، على الرغم من أنني أعتقد أن الزخم وعمليات التفكير متأصلة بشدة دعم قواعد البيانات علاقة تجعل من الصعب على الناس للتبديل. حاليا يتم تدريب مهنة DB بشكل حصري تقريبا في نظرية العلائقية جعل المهنيين DB الخاص مهتم جدا في تجنب OODB والأوساط الأكاديمية يعلم نظرية DB للممارسين بشكل حصري تقريبا على العلائقية.
وحتى الكبيرة، دباس الشركات وأساتذة التيار والمناهج وتتحول الموظفون خارج المطورين على استعداد لOODB تمكن أشعر أنه من غير المحتمل أن نرى الجاذبية الجماهيرية مهما كانت جيدة هو عليه من الجانب التنمية.
حسنًا، إنه أمر غريب أليس كذلك؟هناك مثل هذا الدفع نحو التصميم القائم على المجال باعتباره ذروة التحليل والتصميم الموجه للكائنات، وهناك أنماط مؤسسية متاحة للاستفادة من أنظمة ORM للحفاظ على كائناتنا.من المنطقي تمامًا بالنسبة لي أنه إذا كان تصميم التطبيق الخاص بك موجهًا للكائنات ويركز على المجال في القلب، فإن OODB سيفيد تطبيقك بشكل كبير.
وبصرف النظر عن القضايا المتعلقة بالنضج والاستيعاب، من وجهة نظر فلسفية، قد يبدو OODB مفيدًا أو تطبيق OO.عدم الاضطرار إلى الحفاظ على طبقة التعيين تلك للمبتدئين؛)
لكن انظر، إذا كنت لا تقوم بتصميم محرك أقراص المجال وتستخدم الكائنات ككائنات بيانات وتحب عملياتك المخزنة، فلن تحصل عليها حقًا؛)
وRDBMS هي (مبنية على أساس نظري قوي، وقد تم في السوق لفترة أطول من ذلك بكثير، يمكن نمذجة البيانات أكثر بإخلاص من OODBs في كثير من الحالات، يمكن استخدامها من قبل أكثر دباس من OODBs). هذا هو أحد الأسباب في شكل الصفوف (tuple) العلائقية.
إذا أنا يمكن أن تزيد نقطة فيل: توحيد SQL. لقد حاولت في OODB اللغات الاستعلام مثل OQL لكنها لم تكن قط بهذا اتباع معيار صحيح. كما كانت نوعية لغات الاستعلام المشبوهة، يمكن القول بسبب نقص التوحيد. معايير تعزيز المنافسة، والذي يولد الجودة.
وأحد الأسباب هو أن قواعد البيانات عن البيانات، والأشياء نحو الهياكل والخوارزميات. ذات مرة كنت تأخذ البيانات وتضمين ذلك في الطبقات، والتي تميز العلاقات والعمليات في بنية ثابتة. قواعد البيانات، من ناحية أخرى، ما يقرب من unstructuring البيانات إلى مجموعة من الحالات من الجداول الذرية التي يمكن تجميعها في هياكل مختلفة (عادة مع فئات) من دون إزعاج سلامة الذرات.
وقواعد البيانات هي مشابهة إلى حد ما hexahexaflexagons.
وهذا، وس / ص مصممي الخرائط. من خلالهم، والفرق إلى true OO-بالواجبات يصبح الطريق أقل، في حين تبقى الفوائد المذكورة أعلاه سارية المفعول.
والقرارات التكنولوجيا باهظة الثمن من قبل الناس مع المعرفة التقنية. الشركات التي تستخدم قواعد البيانات العلائقية توظف الكثير من الناس الذين يشعرون بأنهم مهددون من قبل OODBs وبالتالي سوف تجنب تعلم عنهم.
وأعتقد أن هناك سببين الفلسفية.
أولا، يميل الناس عادة إلى فصل استمرار من وظائف حقيقية. بمجرد تجريد بعيدا "الحياة" الكائن بعيدا عن ذلك والاحتفاظ بها في المقام الأول للثبات ويصبح رقما قياسيا، وبعد ذلك هناك ميل إلى التعامل معها على أنها كائن بيانات "هامدة".
وبعد على ذلك، عندما يفكر الناس في مجموعة كبيرة من الأشياء متشابهة جدا، فإنها تبدأ التفكير منهم كما الجداول بدلا من الكائنات.
وأعتقد مع O / R التمييز بدأت تختفي. على سبيل المثال، وأنا استخدم السبات لتفريغ التسلسلات الهرمية الطبقة معقدة حقا في قاعدة بيانات MySQL. ومع ذلك، أنا لا أكتب الاشياء الأداء حاسم لمشروعي ذلك أنا متأكد من انها لم تفعل بكفاءة.
وتستند والسبب في اعتماد بطء في OODB إلى حد كبير على عدد قليل من العوامل الرئيسية التي تجعل قواعد البيانات SQL العلائقية أكثر شعبية و / أو أكثر ملاءمة. بينما قواعد البيانات وجوه المنحى نقية هي الآن في حالة حيث تغلب على الكثير من عيوب النموذج العلائقي، وهناك بعض القطع الرئيسية في عداد المفقودين.
لاحد فإنها تميل إلى يفتقرون إلى الدعم لإدارة قواعد البيانات المركزية، وعلى الرغم من هذا بسرعة يجري تصحيحها في مختلف المنتجات.
والسبب الثاني هو أن عدد قليل جدا من أنظمة تنفيذ لغة الاستعلام القياسية ويعتمد على لغة البرمجة أو لغات الاستعلام متخصصة لاسترجاع ومعالجة البيانات في تخزين بدلا من ذلك. هذا هو سدادة المعرض بالنسبة للكثيرين إذا كان لديهم لتعلم لغة الاستعلام جديدة على رأس عقلية مختلفة تماما من مبرمج تستخدم لحلول NoSQL القائمة. وعلاوة على ذلك، فإن معظم قواعد البيانات SQL استنادا / العلائقية لديها الآن بعض الدعم لتصميم وجوه المنحى، بالإضافة لدينا مغلفة مثل ORM أن استخدام العديد من ل"تجاوز" مشاكل قواعد البيانات العلائقية عدم متوفرة في لغة البرمجة في الاختيار.
ولكن هذه المشاكل موجودة غالبا في البيئات المؤسسية. كما قواعد البيانات جزءا لا يتجزأ من الأجهزة الصغيرة، وتخزين الموقع وفي مجالات مثل الفضاء لأنها أصبحت شعبية جدا في كثير من الحالات استبدالها تماما الحاجة إلى قواعد البيانات العلائقية العادية.
من يعرف ما يخبئه المستقبل؟
والتسلسل التي تقدمها معظم اللغات يتيح لك flaten سمات كائن، وبالتالي تخزين عليها بسهولة في RDBMS وبالمثل استرجاع الأشياء ليست قضية كبيرة. الأساس واسعة ومتينة لا تزال تفتقر مما يعوق استخدام OODBMS لتنفيذها.
وأنا أفكر حاليا للقيام بذلك كما مشروعي رسالة ماجستير لتوفير إطار عام لOODBMS أن يدعم تقريبا جميع المكونات التي يشيع استخدامها في الآن يوم RDBMS مما يوفر غير الخطية DBMS منظم. أثناء الدراسة جئت عبر مشروع يسمى db4o وهو نهج (تنفيذ) استخدام OODBMS لجاوا و. NET فقط، لذلك يمكن أن يكون هذا سبب آخر لعدم وجود عمومية لجميع أنواع المنصات واللغات.
وأعتقد أن هذا بسبب اللاعبين الكبار مثل أوراكل قد تستثمر في قواعد البيانات العلائقية مع حركة الشيئية كان الحصول على الزخم ... علهم تصبح السائدة إذا أوراكل / مايكروسوفت استثمار فيه بطريقة كبيرة ... والتي يبدو من غير المحتمل لأنهم لم يكن لديك سبب قوي للقيام بذلك ... انها سوف تبسيط حياة العديد من المبرمجين ... ولكن "مما يجعل المبرمجين يعيش بساطة" ليست هدفا تجارية جيدة للغاية بالنسبة لهم!
