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

Question

بناءً على القراءة حول الويب ، فائض المكدس ، وفي الغالب هذه المقالات حول إصدار DB الذي تم ربطه من ترميز الرعب ، قمت بطعن في كتابة خطة لإصدار قاعدة البيانات لموقع PHP MySQL الذي يبلغ عمره 8 سنوات.

Database Version Control plan
- Create a db as the "Master Database"
- Create a table db_version (id, script_name, version_number, author, comment, date_ran)   
- Create baseline script for schema+core data that creates this db from scratch, run this on Master Db
- Create a "test data" script to load any db with working data
- Modifications to the master db are ONLY to be made through the db versioning process
- Ensure everyone developing against the Master Db has a local db created by the baseline script
- Procedures for commiting and updating from the Master Db
    - Master Db Commit
        - Perform a schema diff between your local db and the master db
        - Perform a data diff on core data between your local db and master db
        - If there are changes in either or both cases, combine these changes into an update script
        - Collect the data to be added to a new row in db_version table, and add an insert for this into the script
            - new version number = latest master db version number +1
            - author
            - comment
        - The script must be named as changeScript_V.sql where V is the latest master db version +1
        - Run the script against the master db
        - If the script executed succesfully, add it to the svn repository
        - Add the new db_version record to your local db_version table      
    - Update from Master Db
        - Update your local svn checkout to have all the latest change scripts available
        - compares your local db_version table to the master db_version table to determine which change scripts to run
        - Run the required change scripts in order against your local db, which will also update your local db_version table

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

Answer 1

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

• احصل على شخص واحد مسؤول عن ديسيبل (دعنا ندعوه dbperson) - كل تغيير سيناريو/ديسيبل يجب أن يمر عبره. سيتجنب ذلك أي تغييرات غير ضرورية ، وبعض "الإطلالات" من القضايا (على سبيل المثال ، إذا قام شخص ما بنقل فهرسًا لأداء أفضل لاستفساره ، فقد يدمر Hi لأشخاص آخرين ، وربما يقوم شخص ما بإنشاء طاولة لا لزوم لها تمامًا وغير ضرورية ، إلخ...). هذا سيبقي DB نظيفة وفعالة. حتى لو كان يبدو أن هذا هو العمل الكثير لرجل واحد (أو نائبه) ، في الواقع ليس كذلك - نادراً ما يتغير DB.
• يجب أن يمرر كل نص التحقق من خلال DBPerson
• عند الموافقة على البرنامج النصي ، يقوم DBPerson بتعيين رقم ويضعه في مجلد "تحديث"/SVN (...) ، مع ترقيم مناسب (كما اقترحت ، أرقام تدريجية على سبيل المثال).
• بعد ذلك ، إذا كان لديك بعض التكامل المستمر في مكانه ، يتم التقاط البرنامج النصي وتحديث DB (إذا لم يكن لديك تكامل مستمر ، فقم بذلك يدويًا).
• لا تقم بتخزين البرنامج النصي لأكمل قاعدة البيانات ، مع جميع البيانات الموجودة في البرنامج النصي. تخزين قاعدة البيانات الفعلية بدلاً من ذلك. إذا كان لديك فروع من الحل - اطلب من كل فرع مع قاعدة بيانات خاصة به ، أو يمكنك دائمًا الحصول على نصوص تحديث مقسمة لكل فرع حتى تتمكن من التراجع/توجيه فرع آخر. لكنني أوصي حقًا أن يكون لديك ديسيبل منفصل لكل فرع.
• احصل على قاعدة بيانات واحدة دائمًا مع البيانات الافتراضية (سليمة) - لاحتياجات اختبارات الوحدة ، واختبارات الانحدار وما إلى ذلك كلما قمت بالاختبارات ، قم بها على نسخة قاعدة البيانات هذه. يمكنك حتى وضع تنظيف ليلي لقواعد بيانات الاختبار مع القصة الرئيسية (إذا كان ذلك مناسبًا بالطبع).

في بيئة كهذه ، سيكون لديك إصدارات متعددة من قاعدة البيانات:

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

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