قواعد - مميزات وعيوب لغة sql




هل هناك نظام للتحكم في إصدار تغييرات هيكل قاعدة البيانات؟ (15)

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

أنا كثيرا ما واجهت المشكلة التالية.

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

لذلك ، أقوم بالضغط على النظام المباشر وأحصل على خطأ كبير وواضح أنه لا يوجد NewColumnX ، لاف.

بغض النظر عن حقيقة أن هذا قد لا يكون أفضل ممارسة لهذا الموقف ، هل هناك نظام للتحكم في إصدار قواعد البيانات؟ لا يهمني تقنية قاعدة البيانات المحددة. أنا فقط أريد أن أعرف إذا كان هناك واحد. إذا حدث ذلك للعمل مع MS SQL Server ، ثم عظيم.


ألق نظرة على حزمة أوراكل DBMS_METADATA.

على وجه الخصوص ، الطرق التالية مفيدة بشكل خاص:

  • DBMS_METADATA.GET_DDL
  • DBMS_METADATA.SET_TRANSFORM_PARAM
  • DBMS_METADATA.GET_GRANTED_DDL

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

لست متأكدا مما إذا كان هناك شيء بهذه البساطة ل MSSQL.


أنا مدرسة قديمة بعض الشيء ، حيث أستخدم الملفات المصدر لإنشاء قاعدة البيانات. يوجد بالفعل ملفان - project-database.sql و project-updates.sql - الأول للمخطط والبيانات الثابتة ، والثاني للتعديلات. بالطبع ، كلاهما تحت سيطرة المصدر.

عندما تتغير قاعدة البيانات ، أقوم أولاً بتحديث المخطط الرئيسي في project-database.sql ، ثم انسخ المعلومات ذات الصلة إلى project-update.sql ، على سبيل المثال عبارات ALTER TABLE. يمكنني بعد ذلك تطبيق التحديثات على قاعدة بيانات التطوير والاختبار والتكرار حتى تتم بشكل جيد. ثم ، تحقق في الملفات ، واختبر مرة أخرى ، وتطبيق على الإنتاج.

أيضًا ، عادةً ما يكون لدي جدول في db - Config - مثل:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

بعد ذلك ، أضف ما يلي إلى قسم التحديث:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

يتم تغيير db_version فقط عندما يتم إعادة إنشاء قاعدة البيانات ، db_revision إشارة إلى أي مدى يكون db خارج الخط الأساسي.

يمكنني الاحتفاظ بالتحديثات في ملفات منفصلة خاصة بهم ، لكنني اخترت جمعها معًا واستخدام قص ولصق لاستخراج الأقسام ذات الصلة. هناك المزيد من التدبير المنزلي المناسب ، أي إزالة ":" من $ Revision 1.1 $ لتجميدها.


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

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


اجعل بيانات جدولك الأولية مبدئية في وحدة تحكم الإصدار ، ثم أضف عبارات جدول التغيير ، ولكن لا تقم أبدًا بتحرير الملفات ، أو قم فقط بتغيير الملفات المسماة بشكل تسلسلي ، أو حتى كـ "مجموعة تغيير" ، بحيث يمكنك العثور على جميع التغييرات لنشر معين.

الجزء الأصعب الذي يمكنني رؤيته ، هو تتبع التبعيات ، على سبيل المثال ، قد يلزم تحديث جدول نشر معين B قبل الجدول A.


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


في Ruby on Rails ، هناك مفهوم migration - نص سريع لتغيير قاعدة البيانات.

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

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

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


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


لقد استخدمنا MS Team System Database Edition بنجاح كبير. إنه يتكامل مع التحكم في إصدار TFS و Visual Studio أكثر أو أقل بسلاسة ويسمح لنا بإدارة procs المخزنة ، وجهات النظر ، وما إلى ذلك ، بسهولة. يمكن أن يكون حل النزاع أمرًا مؤلمًا ، ولكن تاريخ الإصدار مكتمل بمجرد الانتهاء من ذلك. بعد ذلك ، الهجرة إلى ضمان الجودة والإنتاج بسيطة للغاية.

من العدل أن نقول إنه منتج الإصدار 1.0 ، ومع ذلك ، فإنه لا يخلو من بعض المشاكل.


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

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


وأتساءل أن لا أحد ذكر أداة liquibase قاعدة البيانات ذات المصدر المفتوح والتي تستند إلى Java ويجب أن تعمل في كل قاعدة بيانات تقريبًا تدعم jdbc. بالمقارنة مع القضبان فإنه يستخدم xml بدلاً من ruby ​​لتنفيذ تغييرات المخطط. على الرغم من أنني لا أحب xml للغات المحددة للنطاق ، إلا أن الميزة الرائعة للغاية من xml هي أن قاعدة بيانات fluibase تعرف كيفية استعادة بعض العمليات مثل

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

لذلك لا تحتاج إلى التعامل مع هذا بنفسك

كما يتم دعم بيانات SQL الخالصة أو عمليات استيراد البيانات.


يتيح لك ER Studio عكس مخطط قاعدة البيانات الخاص بك إلى الأداة ويمكنك بعد ذلك مقارنتها بقواعد البيانات المباشرة.

مثال: عكس مخطط التطوير الخاص بك إلى ER Studio - قارنه بالإنتاج وسيدرج كل الاختلافات. يمكنه كتابة التغييرات أو دفعها تلقائيًا.

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


يحتوي PLSQL Developer ، وهو أداة من All Arround Automations ، على مكون إضافي للمستودعات التي تعمل بشكل جيد (ولكن ليس رائعًا) باستخدام Visual Source Safe.

من الويب:

يوفر المكون الإضافي للتحكم في الإصدار تكاملًا ضيقًا بين معرف مطور PL / SQL IDE وأي نظام تحكم في إصدار يدعم مواصفات واجهة SCC لـ Microsoft. >> يتضمن ذلك أنظمة التحكم في الإصدار الأكثر شيوعًا مثل Microsoft Visual SourceSafe و >> Merant PVCS و MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html


يعد Schema Compare for Oracle أداة مصممة خصيصًا لترحيل التغييرات من قاعدة بيانات Oracle الخاصة بنا إلى أخرى. يرجى زيارة عنوان URL أدناه للحصول على رابط التنزيل ، حيث ستتمكن من استخدام البرنامج لتجربة كاملة الوظائف.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm


MyBatis (المعروف سابقًا باسم iBatis) على ترحيل مخطط ، أداة للاستخدام في سطر الأوامر. هو مكتوب في جافا رغم أنه يمكن استخدامه مع أي مشروع.

لتحقيق ممارسة جيدة لإدارة قواعد البيانات ، نحتاج إلى تحديد بعض الأهداف الرئيسية. وبالتالي ، يسعى نظام ترحيل مخطط MyBatis (أو MyBatis Migrations لـ short) إلى:

  • العمل مع أي قاعدة بيانات ، جديدة أو موجودة
  • الاستفادة من نظام التحكم في المصدر (مثل التخريب)
  • تمكين المطورين أو الفرق المتزامنة للعمل بشكل مستقل
  • السماح للصراعات واضحة جدا ويمكن التحكم فيها بسهولة
  • السماح للهجرة للأمام وللخلف (التطور والانتقال على التوالي)
  • اجعل الحالة الحالية لقاعدة البيانات سهلة الوصول ومفهومة
  • تمكين عمليات الترحيل على الرغم من امتيازات الوصول أو البيروقراطية
  • العمل مع أي منهجية
  • يشجع الممارسات الجيدة والمتناسقة






version-control