عندما لا يمكنك استخدام قاعدة بيانات علائقية ؟ [مغلقة]

Question

وبصرف النظر عن جوجل/bigtable السيناريو عندما لا يمكنك استخدام قاعدة بيانات علائقية ؟ لماذا لا ، وما ينبغي أن تستخدم ؟ (هل تعلم بالطريقة الصعبة'?)

Answer 1

في تجربتي, لا يجب استخدام قواعد البيانات العلائقية عند أي واحد من هذه المعايير صحيحا:

• البيانات الخاصة بك هو منظم كما الهرمي أو الرسم البياني (الشبكة) التعسفي العمق ،
• نموذجية نمط الوصول تؤكد القراءة أكثر من الكتابة ، أو
• لا يوجد شرط المخصص الاستعلامات.

عميق الهرمية والرسوم البيانية لا يترجم إلى الجداول العلائقية.حتى مع مساعدة من الملكية امتداد مثل أوراكل CONNECT BY, مطاردة الأشجار الجبارة الألم باستخدام SQL.

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

أخيرا, كنت ببساطة لا تحتاج إلى قاعدة بيانات علائقية مع كاملة لغة الاستعلام إذا كان هناك أي غير متوقعة الاستفسارات المتوقعة.إذا كان هناك أي تناسب طرح أسئلة مثل "كيف العديد من 5%-خصم الحاجيات الأزرق هل نبيع على الساحل الشرقي تجميعها من قبل مندوب مبيعات؟", و لن يكون هناك أبدا ، ثم أنت يا سيدي يمكن أن يعيش من DB.

Answer 2

قاعدة بيانات علائقية النموذج يجعل بعض الافتراضات حول استخدام البيانات.

• علاقة يتكون من مجموعة غير مرتبة من الصفوف.
• جميع الصفوف في علاقة لها نفس مجموعة من الأعمدة.
• كل عمود ثابت اسم و نوع البيانات و المعنى الدلالي على جميع الصفوف.
• الصفوف في علاقة بتحديد القيم الفريدة في عمود المفتاح الأساسي(s).
• الخ.

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

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

عموما ، يجب استخدام الأداة المناسبة لكل وظيفة.

انظر أيضا إجابة أخرى إلى "الجيل المقبل من قواعد البيانات."

Answer 3

هناك ثلاثة نماذج البيانات (C. J. تاريخ E. F. كود) وأنا أضيف ملف ثابت هذا:

• شقة file(s) (هيكل يختلف من 'غبي' شقة النص إلى ملفات تتفق مع القواعد التي إلى جانب أدوات ذكية جدا ذكي الأمور, أعتقد المجمعين و ما يمكن القيام به ، ضيق في تطبيق النمذجة أشياء جديدة)
• الهرمية (الأشجار مجموعات متداخلة - أمثلة:xml وغيرها من اللغات الترميزية, التسجيل, المخططات التنظيمية ، وما إلى ذلك ؛ أي شيء يمكن أن يكون على غرار لكن سلامة القواعد ليست سهلة للتعبير عن واسترجاعها من الصعب تحسين تلقائيا بعض استرجاع سريع وبعضها بطيء جدا )
• شبكة (الشبكات البيانية - أمثلة:الملاحية قواعد البيانات, وصلات, الويب الدلالي ، مرة أخرى أي شيء تقريبا يمكن أن تكون على غرار لكن التلقائي الأمثل من استرجاع مشكلة)
• العلائقية (أول المسند المنطق - على سبيل المثال:قواعد البيانات العلائقية ، التحسين التلقائي استرجاع)

كل هرمي الشبكة يمكن أن تكون ممثلة في العلائقية relational يمكن التعبير عنها في الأخريين.

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

الفوائد تأتي بتكلفة معظم المشاريع تجد أن نسبة جيدة من أجل أنظمة (موضوع التطبيق) التي تقوم بتخزين البيانات على المدى الطويل بطريقة من شأنها أن تكون قابلة للاستخدام في المستقبل المنظور.

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

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

أو إذا كنت ببساطة لا يهتمون سلامة البيانات الخاصة بك كثيرا (الذي يمكن أن يكون على ما يرام).

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

مثال واحد على كيف جيدة النموذج العلائقي ، المنظمة البحرية الدولية ، هو نسبة من التعقيد مقابل ضيق من الأسئلة التي سوف تجد أن تنطوي على SQL.

Answer 4

وأقترح عليك زيارة عالية التدرجية بلوق ، الذي يناقش هذا الموضوع تقريبا على أساس يومي، ولها العديد من المقالات حول المشاريع التي اختارت توزيع التجزئة، الخ على RDMBS.

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

Answer 5

وقبل خمسة عشر عاما كنت أعمل على نظام مخاطر الائتمان (أساسا شجرة نظام المشي كبير). كنا باستخدام سايبيس على HPUX وسولاريس وperformnce كان يقتلنا. نحن استأجرت في استشاريين المباشر من Sybase الذي قال انه لا يمكن القيام به. ثم تحولنا إلى قاعدة بيانات OO (مخزن كائن في هذه الحالة) وحصلت على نحو زيادة 100X الأداء (وكان رمز حول 100X أسهل في الكتابة أيضا)

ولكن هذه الحالات نادرة جدا - قاعدة بيانات علائقية هي الخيار الأول جيد

Answer 6

عند يختلف كنت مخطط الكثير سيكون لديك وقتا عصيبا مع قواعد البيانات العلائقية. هذا هو المكان قواعد بيانات XML أو قواعد البيانات زوج المفاتيح ذات قيمة تعمل على أفضل وجه. أو هل يمكن استخدام IBM DB2 ويكون كل من البيانات العلائقية والبيانات XML يديرها محرك قاعدة بيانات واحدة.

Answer 7

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

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

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