كيف يمكنك إدارة ترقيات المخطط إلى قاعدة بيانات الإنتاج؟

Question

يبدو أن هذه منطقة تم التغاضي عنها ويمكن أن تستفيد حقًا من بعض المعرفة.ما هي أفضل الممارسات الخاصة بك من أجل:

• إجراء إجراء الترقية
• التراجع في حالة وجود أخطاء
• مزامنة التعليمات البرمجية وتغييرات قاعدة البيانات
• الاختبار قبل النشر
• آليات تعديل الجدول

إلخ...

Answer 1

هذا سؤال عظيم.(هناك احتمال كبير أن ينتهي الأمر بمناقشة قاعدة بيانات تم تطبيعها مقابل عدم تطبيعها.. وهو ما لن أبدأ فيه...حسنًا الآن لبعض المدخلات.)

بعض الأشياء التي قمت بها في أعلى رأسي (سأضيف المزيد عندما يكون لدي المزيد من الوقت أو أحتاج إلى استراحة)

تصميم العميل - هذا هو المكان الذي تسبب فيه طريقة VB الخاصة بـ SQL المضمنة (حتى مع البيانات المعدة) في حدوث مشكلة.يمكنك قضاء الأعمار في العثور على تلك العبارات فقط.إذا كنت تستخدم شيئًا مثل Hibernate ووضعت قدرًا كبيرًا من SQL في الاستعلامات المسماة، فلديك مكان واحد لمعظم SQL (ليس هناك ما هو أسوأ من محاولة اختبار SQL الموجود داخل بعض عبارات IF ولا تضغط على "المشغل" المعايير في الاختبار الخاص بك لبيان IF).قبل استخدام السبات (أو أي نظام آخر) عندما أقوم باستخدام SQL مباشرة في JDBC أو ODBC، كنت سأضع جميع عبارات SQL إما كحقول عامة لكائن (مع اصطلاح تسمية) أو في ملف خاصية (أيضًا مع تسمية اصطلاح القيم يقول PREP_STMT_xxxx.واستخدم إما الانعكاس أو التكرار على القيم عند بدء التشغيل في أ) حالات الاختبار ب) بدء تشغيل التطبيق (تسمح لك بعض أنظمة إدارة قواعد البيانات (RDBMS) بالتجميع المسبق للبيانات المعدة قبل التنفيذ، لذا عند تسجيل الدخول بعد بدء التشغيل، سأقوم بتجميع الإعداد مسبقًا- stmts عند بدء التشغيل لإجراء الاختبار الذاتي للتطبيق.حتى بالنسبة لمئات البيانات حول نظام RDBMS الجيد، فإن ذلك لا يستغرق سوى بضع ثوانٍ.ومرة واحدة فقط.وقد أنقذ مؤخرتي كثيرًا.في أحد المشاريع، لم يتواصل مسؤولو قواعد البيانات (فريق مختلف في بلد مختلف) ويبدو أن المخطط يتغير ليلاً، دون سبب.وفي كل صباح، حصلنا على قائمة بالمكان الذي تعطل فيه التطبيق بالضبط، عند بدء التشغيل.

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

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

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

إدارة التغيير إلى المخطط -> هل تقوم بتحديث الجدول أو إضافة علاقات 1-1 إلى الجداول الجديدة؟لقد رأيت الكثير من المتاجر التي تصل دائمًا إلى البيانات عبر طريقة العرض لهذا السبب.يسمح ذلك بتغيير أسماء الجداول والأعمدة وما إلى ذلك.لقد لعبت مع فكرة التعامل مع طرق العرض فعليًا مثل الواجهات في COM.أي.تقوم بإضافة طريقة عرض جديدة للوظائف/الإصدارات الجديدة.في كثير من الأحيان، ما يوصلك إلى هنا هو أنه يمكنك الحصول على الكثير من التقارير (خاصة التقارير المخصصة للمستخدم النهائي) التي تتخذ تنسيقات الجداول.تسمح لك طرق العرض بنشر تنسيق جدول جديد ولكنها تدعم تطبيقات العميل الحالية (تذكر كل تلك التقارير المخصصة المزعجة).

تحتاج أيضًا إلى كتابة البرامج النصية للتحديث والتراجع.ومرة أخرى اختبار، اختبار، اختبار...

------------ حسنًا - هذا وقت مناقشة عشوائي بعض الشيء --------------

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

لقد كان الأمر يكلف الكثير من المال لإجراء الترقيات.كثيراً.أي.التخلي عن أسابيع من الاستشارات المجانية في الموقع.

وقد وصل الأمر إلى حد الرغبة في إضافة ميزات جديدة أو تحسين الكود.بعض التعليمات البرمجية الموجودة تستخدم الإجراءات المخزنة، لذلك كان لدينا نقاط مشتركة حيث يمكننا إدارة التعليمات البرمجية.لكن المناطق الأخرى كانت عبارة عن ترميز SQL مضمن بتنسيق HTML.وكان ذلك أمرًا رائعًا للوصول إلى السوق بسرعة، ولكن مع كل تفاعل للميزات الجديدة، تضاعفت تكلفة الاختبار والصيانة على الأقل.لذلك عندما كنا نتطلع إلى سحب رمز نوع php، ووضع طبقات البيانات (كان ذلك في الفترة 2001-2002، قبل أي ORM وما إلى ذلك) وإضافة الكثير من الميزات الجديدة (ملاحظات العملاء)، نظرنا في هذه المشكلة المتعلقة بكيفية هندسة الترقيات في النظام.وهذا أمر مهم، حيث أن الترقيات تكلف الكثير من المال للقيام بها بشكل صحيح.الآن، تتعامل معظم الأنماط وجميع الأشياء الأخرى التي يناقشها الأشخاص مع درجة من الطاقة مع كود OO الذي يتم تشغيله، ولكن ماذا عن حقيقة أن بياناتك يجب أن أ) تتكامل مع هذا المنطق، ب) المعنى وأيضًا بنية يمكن أن تتغير البيانات بمرور الوقت، وفي كثير من الأحيان بسبب الطريقة التي تعمل بها البيانات، ينتهي بك الأمر إلى وجود الكثير من العمليات/التطبيقات الفرعية في مؤسسة عملائك التي تحتاج إلى تلك البيانات -> التقارير المخصصة أو أي تقارير مخصصة معقدة، بالإضافة إلى المهام المجمعة التي تم إجراؤها لخلاصات البيانات المخصصة وما إلى ذلك.

مع أخذ هذا في الاعتبار، بدأت اللعب بشيء على يسار الملعب.كما أن لديها بعض الافتراضات.أ) تتم قراءة البيانات بشكل مكثف أكثر من الكتابة.ب) تحدث التحديثات، ولكن ليس على مستويات البنك، أي.واحد أو 2 ثانية يقول.

كانت الفكرة هي تطبيق طريقة عرض COM/Interface على كيفية وصول العملاء إلى البيانات عبر مجموعة من الجداول CONCRETE (والتي تختلف مع تغييرات المخطط).يمكنك إنشاء عرض منفصل لكل عملية كتابة - التحديث والحذف والإدراج والقراءة.هذا مهم.سيتم تعيين طرق العرض مباشرة إلى جدول، أو تسمح لك بتشغيل جدول وهمي يقوم بالتحديثات الحقيقية أو الإدخالات وما إلى ذلك.ما أردته بالفعل هو نوع من المراوغة على مستوى يمكن اكتشافه والذي لا يزال من الممكن استخدامه بواسطة التقارير البلورية وما إلى ذلك.ملاحظة - بالنسبة للإدراجات والتحديث والحذف، يمكنك أيضًا استخدام العمليات المخزنة.وكان لديك نسخة لكل إصدار من المنتج.بهذه الطريقة، كان الإصدار 1.0 الخاص بك يحتوي على نسخته من المخطط، وإذا تغيرت الجداول، فسيظل لديك الإصدار 1.0 VIEWS ولكن مع منطق الواجهة الخلفية الجديد للتعيين إلى الجداول الجديدة حسب الحاجة، ولكن كان لديك أيضًا طرق عرض الإصدار 2.0 التي من شأنها أن تدعم حقول جديدة الخكان هذا في الحقيقة فقط لدعم التقارير المخصصة، والتي إذا كنت رجل أعمال وليس مبرمجًا، فمن المحتمل أن يكون هذا هو الهدف الأساسي وراء حصولك على المنتج.(يمكن أن يكون منتجك سيئًا، ولكن إذا كان لديك أفضل التقارير في العالم فلا يزال بإمكانك الفوز، والعكس صحيح - يمكن أن يكون منتجك أفضل الميزات، ولكن إذا كان الأسوأ في إعداد التقارير، فمن الممكن أن تخسره بسهولة).

حسنًا، آمل أن تساعد بعض هذه الأفكار.

Answer 2

ليكيباس

موقع liquibase.org:

1. فهو يفهم تعريفات السبات.
2. فهو يولد تحديث مخطط SQL أفضل من السبات
3. يقوم بتسجيل الترقيات التي تم إجراؤها على قاعدة البيانات
4. يتعامل مع التغييرات المكونة من خطوتين (أياحذف العمود "foo" ثم أعد تسمية عمود مختلف إلى "foo")
5. فهو يتعامل مع مفهوم الترقيات المشروطة
6. يستمع المطور فعليًا إلى المجتمع (مع وضع السبات إذا لم تكن ضمن الحشد أو مبتدئًا - فسيتم تجاهلك بشكل أساسي.)

http://www.liquibase.org

Answer 3

رأي

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

Answer 4

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

Answer 5

على العموم قاعدتي هي:"يجب أن يدير التطبيق مخططه الخاص."

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

لقد حققت نجاحًا كبيرًا في استخدام ميزة Hibernates SchemaUpdate لإدارة هياكل الجدول.ترك البرامج النصية للترقية للتعامل فقط مع تهيئة البيانات الفعلية وإزالة الأعمدة من حين لآخر (لا يقوم SchemaUpdate بذلك).

فيما يتعلق بالاختبار، نظرًا لأن الترقيات جزء من التطبيق، فإن اختبارها يصبح جزءًا من دورة الاختبار للتطبيق.

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

Answer 6

هذه كلها مواضيع ذات أهمية، ولكن هنا توصيتي للتحديث.

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

Answer 7

لقد سمعت أشياء جيدة عنه نظام ترحيل المخطط iBATIS 3:

دليل المستخدم: http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-Migrations.pdf

Answer 8

كما قال بات، استخدم liquibase.خاصة عندما يكون لديك العديد من المطورين الذين لديهم قواعد بيانات DEV الخاصة بهم التي تقوم بإجراء تغييرات ستصبح جزءًا من قاعدة بيانات الإنتاج.

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

لكن Liquidbase أفضل تنظيمًا من ذلك!