كم التوافق لم محركات DB لها على مستوى SQL؟

Question

ودعونا نقول أردت أن يكون أحد التطبيقات التي يمكن بسهولة تبديل DB في الخلفية.
أنا أفكر في معظمها من SQL Server كما الخلفية الأساسية، ولكن مع المرونة للذهاب محرك DB آخر. يبدو فايربيرد وكيو أن يكون (من وجهة نظري وجيزة ويكيبيديا رحلة) الأكثر شيوعا في ث / SQL خادم (بالإضافة إلى أنها خالية).

وكيف مماثلة من شأنه الإعداد DB، والوصول إلى والاستعلامات وغيرها .. يكون لفايربيرد، كيو وMS SQL خادم؟

Answer 1

وعملت على مشروع واحد حيث كان شرطا مطلقا لدعم العديد من قواعد البيانات، بما في ذلك ما لا يقل عن الوصول، SQL Server و Oracle.

وهكذا وأنا أعلم أنه يمكن القيام به. معظمهم DML (SELECT، UPDATE، INSERT ...) هو نفسه وبالتأكيد لم يكن لدينا مشاكل كبيرة مما يجعل العمل في جميع قواعد البيانات - فقط مضايقات في بعض الأحيان. كانت الخلية استثناء في ذلك الوقت كما كان ببساطة غير قادرة بما فيه الكفاية.

ولقد وجدنا معظم الاختلافات في DDL، ولكن مع العمارة الصحيحة (التي كانت لدينا)، لم يكن من الصعب أن يثبت ذلك.

والشيء الوحيد الذي تسبب لنا مشكلة وتوليد هوية فريدة من نوعها - autoincrement غير القياسية. Fortuantely في قاعدة بيانات لنحو 40 الجداول لم يكن هناك سوى عدد قليل من الأماكن التي كانت معرف فريد الحاجة (تصميم DB جيد). في النهاية نحن توليد معرف فريد في التعليمات البرمجية، والتعامل مع أي اشتباكات (كل شيء في المعاملات).

وولم تجعل الأمور أسهل لأننا تجنبت استخدام autoincrement لحقول ID، فإنه من الصعب أن نفكر في مفاتيح فريدة من نوعها - ولكن أفضل على المدى البعيد

Answer 2

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

إذا كنت ترغب في النظر في الكيفية التي تختلف - من الأمثلة الجيدة هي هويات والحصول على معرف السجل الأخير إدراجها-تزايد السيارات

Answer 3

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

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

Answer 4

وكما أشار إلى ذلك إجابات أخرى، نظم إدارة قواعد البيانات تختلف بعنف بمجرد تجاوز SELECT الأساسي / INSERT الاشياء (وأحيانا هناك).

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

وعلى وجه الخصوص، قد دفع للنظر في ORMs الشعبية (السبات، nHibernate الخ). وعادة ما تقدم DB الاستقلال كنوع من الآثار الجانبية. على الأقل لديها السبات أيضا لغة الاستعلام الخاصة التي سيتم تلقائيا تترجم إلى SQL لنظم إدارة قواعد البيانات الذي تستخدمه.