ما هي العملية الخاصة بك للتعامل مع تغييرات مخطط قاعدة البيانات في فريق dev؟

Question

فيما يلي سؤال أكثر عمومية حول كيفية معالجة تغييرات مخطط قاعدة البيانات في فريق تطوير.

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

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

كنت أتساءل ... كيف تتعامل يا رفاق هذا النوع من الأشياء؟ للحصول على شفرة المصدر، نستخدم SVN.

حقا نقدر المدخلات الخاصة بك!

شكرا، مايكل

Answer 1

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

Answer 2

على الأقل، يجب أن يكون لديك نصوص لجميع الكائنات في قاعدة البيانات (الجداول، الإجراءات المخزنة، إلخ) تحت التحكم بالمصدر.

لا أعتقد أن تغييرات المخطط البريدية هي خيار حقيقي لفريق تطوير احترافي.

Answer 3

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

تضمن الإنشاء الليلي للتطبيق بناء قاعدة بيانات (SQL Server). حصلت قاعدة البيانات على خادم اختبار DB. ثم كان لدى كل مطور حزمة DTS (كان هذا منذ فترة واحدة، وأنا متأكد من أنها تمت ترقيتها إلى حزم SSIS) لسحب ذلك بناء DB الليلي وفقا لبيئة DB المحلية الخاصة بهم.

احتفظت هذه النسخة الرئيسية في موقع واحد ووضع ONUS على المطورين للحفاظ على قواعد بيانات DEV المحلية جديدة.

Answer 4

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

1. سوف ترقية مخطط قاعدة البيانات وتعديل أي بيانات موجودة بشكل مناسب، و
2. سيتم تحديث رقم الإصدار في قاعدة البيانات.

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

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

Answer 5

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

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

Answer 6

بالتأكيد سأبقي مخطط قاعدة البيانات في التحكم في التعليمات البرمجية المصدر.

في وظيفتي الحالية، في كل مرة هناك تغيير مخطط، نكتب SQL للتغيير (ALTER TABLE XYZ إضافة عمود ...) ووضعه في SVN. ثم يمكن للمطورين تحديث قواعد بيانات الاختبار عن طريق تشغيل هذا البرنامج النصي. انها خرقاء جدا ولكنها تعمل.

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

أعتقد أنه يجب أن يكون هناك أداة Generic SQL للقيام بذلك. ربما هناك، لكنني لم أر واحدة أبدا.