إدارة تغيير قاعدة البيانات - الإعداد للبرامج النصية الأولية ، البرامج النصية للترحيل اللاحقة

Question

لقد حصلت على سير عمل إدارة تغيير قاعدة البيانات في المكان. يعتمد على البرامج النصية SQL (لذلك ، ليس حلًا مُدارًا قائمًا على الرمز).

يبدو الإعداد الأساسي مثل هذا:

Initial/
    Generate Initial Schema.sql
    Generate Initial Required Data.sql
    Generate Initial Test Data.sql
Migration
     0001_MigrationScriptForChangeOne.sql
     0002_MigrationScriptForChangeTwo.sql
     ...

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

سؤالي هو ، في هذا النوع من الإعداد ، هل من المفيد أيضًا الحفاظ على هذا:

Current/
    Stored Procedures/
        dbo.MyStoredProcedureCreateScript.sql
        ...
    Tables/
        dbo.MyTableCreateScript.sql
        ...
    ...

من خلال "هذا" أعني دليل البرامج النصية (مفصولة بنوع الكائن) الذي يمثل البرامج النصية إنشاء لدور الحالي/الأحدث إصدار قاعدة البيانات.

لسبب ما ، أحب الفكرة حقًا ، لكن لا يمكنني تبريرها بشكل ملموس. هل فاتني شيء؟

ستكون المزايا:

• بالنسبة إلى Dev and Source Control ، سيكون لدينا نفس إعداد الكائن لكل ملف الذي اعتدنا عليه
• للنشر ، يمكننا تدوير مثيل DB جديد إلى أحدث إصدار إما عن طريق تشغيل Arirent+Migrate ، أو عن طريق تشغيل البرامج النصية من التيار/
• بالنسبة إلى DEV ، لا نحتاج إلى مثيل DB يعمل من أجل القيام بالتطوير. يمكننا القيام بتطوير "غير متصل" على المجلد الحالي/ المجلد.

ستكون العيوب:

• لكل تغيير ، نحتاج إلى تحديث البرامج النصية في المجلد الحالي/ المجلد ، وكذلك إنشاء برنامج نصي للترحيل (في الترحيل/ المجلد)

ويرجع الفضل في ذلك مسبقا لأية مساهمة!

Answer 1

في الواقع ، هذه هي أفضل طريقة. على الرغم من أن الأمر مرهق كما قد يبدو ، فهو أفضل من بدائل استخدام SQL مقارنة الأدوات أو نشر ملف VSDB .SCHEMA. لقد جادلت بالضبط عن نهج SMAE لبعض الوقت الآن: التحكم في الإصدار وقاعدة البيانات الخاصة بك. تنشر تطبيقاتي مخطط V1 من البرنامج النصي الأولي ، ثم تشغيل البرنامج النصي للترقية لكل إصدار. يعرف كل برنامج نصي كيفية الترقية من الإصدار من N-1 إلى N ، فقط. النتيجة النهائية هي الإصدار الحالي.

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

إذا كنت تشعر بالسوء لاستخدام عملية النشر هذه (البرنامج النصي لنشر V1. ثم قم بتطبيق v1.1 ، ثم v1.2 ... حتى يتم تطبيق V4.5 ، الحالي) ، ضع ذلك في الاعتبار: يتم استخدام نفس العملية بالضبط بواسطة SQL Server داخليًا لترقية قاعدة البيانات بين الإصدارات. عندما تقوم بإرفاق قاعدة بيانات قديمة ، ترى "قاعدة البيانات الشهيرة تعمل على الترقية من الإصدار 611 إلى 612" وترى أن الترقية تذهب خطوة بخطوة, ، لا يتم الترقية مباشرة إلى الإصدار 651 الحالي (أو أي شيء حالي في قضيتك). كما لا تقوم الترقية بتشغيل أداة فرق لنشر V 651 على v. 611. وذلك لأن أفضل النهج هو الذي تستخدمه للتو ، وترقية خطوة واحدة في الوقت المناسب.

وإضافة إجابة فعلية على سؤالك ، بعد نشر صراخ مائل إلى حد ما (هو موضوع لدي آراء قوية ، هل يمكنك معرفة ذلك؟): أعتقد أنه من المهم أن يكون لدي نسخة نصية من الإصدار الحالي ، لكنني أعتقد ذلك يجب أن تكون عملية تكامل متجاورة يمكن تسليمها. بمعنى آخر ، يجب على خادم البناء إنشاء قاعدة البيانات الحالية (باستخدام البرامج النصية للترقية) ، وبعد ذلك ، كخطوة بناء ، قم بإجراء البرنامج النصي على قاعدة البيانات وإنتاج قطرة بناء مع البرنامج النصي لمخطط الإصدار الحالي. ولكن يجب استخدام هذه الأشياء فقط كمرجع للبحث وفحص الكود ، وليس كإجراء قابلة للتسليم ، 2C.

Answer 2

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

Answer 3

مارتن ،

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

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

الحجز الوحيد الذي لدي حول نهجك هو المخطط الحالي/السابق حسب نوع الكائن. يجب إنشاء هذه البرامج النصية تلقائيًا ، من إلقاء قاعدة البيانات نفسها. إذا كنت تستطيع تصنيفها تلقائيًا حسب النوع ، فمن الرائع! إذا لم يكن الأمر كذلك ، افعل ما تستطيع لجعلها سهلة التنقل ، ولكن يجب دائمًا إنشاء القاعدة التوجيهية "تلقائيًا من قاعدة بيانات حية".