التحكم في مصدر قاعدة البيانات مقابلالبرامج النصية لتغيير المخطط
-
15-09-2020 - |
سؤال
يعد إنشاء قاعدة بيانات وصيانتها ثم نشرها/تطويرها بشكل أكبر بواسطة العديد من المطورين أمرًا يحدث في تطوير البرامج طوال الوقت.نقوم بإنشاء برنامج نصي للبناء، ونحافظ على المزيد من البرامج النصية للتحديث التي يتم تطبيقها مع نمو قاعدة البيانات بمرور الوقت.هناك العديد من الطرق لإدارة ذلك، بدءًا من التحديثات اليدوية وحتى تطبيقات وحدة التحكم/إنشاء البرامج النصية التي تساعد في أتمتة هذه العمليات.
هل انتقل أي شخص قام ببناء/إدارة هذه العمليات إلى حل التحكم بالمصادر لإدارة مخطط قاعدة البيانات؟إذا كان الأمر كذلك، فما هو الحل الأفضل الذي وجدوه؟هل هناك أي عيوب يجب تجنبها؟
يبدو أن Red Gate لاعب كبير في عالم MSSQL ويبدو التحكم في مصدر قاعدة البيانات الخاصة به مثيرًا للاهتمام للغاية:http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm
على الرغم من أنه لا يبدو أنه يحل محل عملية إدارة البيانات (الافتراضية)، إلا أنه يستبدل فقط نصف عملية إدارة التغيير من وجهة نظري.
(عندما أتحدث عن البيانات، أعني قيم البحث وهذا النوع من البيانات، البيانات التي يجب نشرها افتراضيًا أو في سيناريو DR)
نحن نعمل في بيئة .Net/MSSQL، لكنني متأكد من أن الفرضية هي نفسها في جميع اللغات.
المحلول
أسئلة مماثلة
واحد أو أكثر من هذه الأسئلة الحالية قد تكون مفيدة:
- li> أفضل طريقة لإدارة تغييرات قاعدة البيانات
- li href="https://stackoverflow.com/questions/763301/mysql-database-change-Tracking"> تغيير قاعدة بيانات MySQL تتبع
- li> قاعدة بيانات SQL Server تغيير سير العمل أفضل الممارسات
- li> التحقق من تغييرات قاعدة البيانات (التحكم في الإصدار)
- نقل التغييرات من DEV DB إلى الإنتاج DB
- li> تغييرات تتبع في بنية قاعدة البيانات
أو بحث عن تغيير قاعدة البيانات
نصائح أخرى
أعتني بمستودع بيانات تم تطويره داخليًا بواسطة البنك الذي أعمل فيه.يتطلب هذا التحديث المستمر، ولدينا فريق مكون من 2-4 مطورين يعملون عليه.
نحن محظوظون لأنه لا يوجد سوى مثيل واحد من "منتجنا"، لذلك لا يتعين علينا تلبية احتياجات النشر إلى مثيلات متعددة قد تكون في إصدارات مختلفة.
نحتفظ بملف نصي للإنشاء لكل كائن (جدول، عرض، فهرس، إجراء مخزن، مشغل) في قاعدة البيانات.
نحن نتجنب استخدام ALTER TABLE
كلما أمكن ذلك، مفضلاً إعادة تسمية الجدول وإنشاء الجدول الجديد وترحيل البيانات إليه.وهذا يعني أنه ليس علينا أن ننظر إلى التاريخ ALTER
البرامج النصية - يمكننا دائمًا رؤية الإصدار المحدث من كل جدول من خلال النظر في البرنامج النصي الخاص بإنشائه.يتم إجراء الترحيل بواسطة برنامج نصي منفصل للترحيل - ويمكن إنشاء هذا تلقائيًا جزئيًا.
في كل مرة نقوم فيها بإصدار، يكون لدينا برنامج نصي يقوم بتشغيل برامج الإنشاء / البرامج النصية للترحيل بالترتيب المناسب.
لعِلمِكَ:نحن نستخدم Visual SourceSafe (yuck!) للتحكم في التعليمات البرمجية المصدر.
لقد كنت أبحث عن أداة تحكم مصدر SQL Server - وافترضت الكثير من الإصدارات المميزة التي تقوم بعمل المهمة - باستخدام SQL Server Management Studio كمخلص.
lavibase هو واحد مجاني ولكنني لم أحصل عليه تماما مع احتياجاتي.
هناك منتج مجاني آخر هناك على الرغم من أن هذا يعمل يقف من SSMS وينصوص الكائنات والبيانات إلى ملف مسطح.
يمكن بعد ذلك ضخ هذه الكائنات في مثيل خادم SQL جديد سيتم إعادة إنشاء كائنات قاعدة البيانات بعد ذلك.
انظر gitsql
ربما تسأل عن lovibase ؟