مخطط بقع الممارسات

Question

لدينا مخطط في بوستجرس ، ونحن نريد أن معهد طريقة جيدة لتطبيق مخطط بقع.

حاليا, لدينا سلسلة من DDL الملفات التي تخلق مخطط, الجداول, متواليات, وظائف, الخ.لدينا أيضا عدد سكانها النصي بيئات الاختبار.هذه الملفات يتم إعادة إنشاء قاعدة البيانات لدينا بيئات التنمية, يختبر, etc.

لدينا أيضا عدد من "تصحيح" الملفات التي تتوافق مع إصدارات النظام.ie.بقع/1.0.0.sql, بقع/1.0.1.sql, الخ.وتستخدم هذه الملفات إلى تحديث انطلاق وإنتاج قواعد البيانات.

هذه العملية يعمل بالنسبة لنا حتى الآن ، ولكن كان هناك بعض النقاش في كيفية التصحيح المخطط.

أنا الغريب ما الآخرين هناك ، باعتبارها عملية التصحيح التدريج الإنتاج المخطط و كيفية إدارة الإصدارات من قاعدة البيانات.

وذلك بفضل!

Answer 1

في العمل لـ SQL Server نكتب مخطط تغيير النصوص أن أول دحر تغيير (idempotently ، وبالتالي فإن التراجع القسم يعمل بشكل جيد حتى لو كان تغيير المخطط لم تطبق حتى الآن) ، ثم قسم لتطبيق التغيير.في tsql ضمن فمن السهل أن نظرة خاطفة في النظام كتالوج أو جداول أخرى لمعرفة ما إذا جداول/أعمدة/مؤشرات/الصفوف موجودة بالفعل و لا شيء لم يكن.

في كيو, كنت قليلا أكثر تقييدا مع ما الأوامر يمكنك ببساطة إرسال إلى ملقم-- ولكن من ناحية أخرى ، DDL هو المعاملات ، حتى نصف تطبيق مخطط التغيير لا ينبغي أن يحدث.لقد تكيفت مخطط اعتدت في العمل لاستخدامها في بلدي مشاريع صغيرة جدا (مبالغة ؟ ولكن حتى هنا لدي dev/اختبار db و "ريال مدريد" ديسيبل) ، على سبيل المثال:

\echo Rolling back schema change #35

BEGIN;

DELETE FROM schema_version WHERE schema_id = 35;

DROP TABLE IF EXISTS location_coordinates;
DROP FUNCTION IF EXISTS location_coordinates_populate();

END;

\echo Applying schema change #35

BEGIN;

INSERT INTO schema_version(schema_id, description) VALUES(35, 'Add location_coordinates table');

CREATE TABLE location_coordinates(
 location_id INT PRIMARY KEY REFERENCES location(location_id),
 latitude FLOAT NOT NULL,
 longitude FLOAT NOT NULL,
 earth_coordinates earth NOT NULL,
 box_10miles cube NOT NULL
);

GRANT SELECT, INSERT, UPDATE, DELETE ON location_coordinates TO ui;

CREATE FUNCTION location_coordinates_populate() RETURNS TRIGGER LANGUAGE 'plpgsql' AS $$
BEGIN
  new.earth_coordinates := ll_to_earth(new.latitude, new.longitude);
  new.box_10miles := earth_box(new.earth_coordinates, 10 * 1609.344);
  RETURN new;
END
$$;

CREATE TRIGGER location_coordinates_populate BEFORE INSERT OR UPDATE ON location_coordinates
 FOR EACH ROW EXECUTE PROCEDURE location_coordinates_populate();

INSERT INTO location_coordinates(location_id, latitude, longitude)
 SELECT location_id, latitude, longitude FROM location WHERE latitude IS NOT NULL AND longitude IS NOT NULL;

CREATE INDEX location_coordinates_10miles ON location_coordinates USING gist (box_10miles);

END;

\echo Done

هذا السيناريو يمكن تشغيلها على قاعدة البيانات فقط مع "psql -f مخطط التغييرات/35.sql".فقط الاستغناء تصل إلى "تطبيق..." رسالة يمكنني الحصول على أوامر للفة مرة أخرى.و كما ترون التغيير يحافظ على بيانات تعريف الجدول "schema_version" حتى أستطيع أن أرى التغييرات التي يتم تطبيقها.كامل تغيير يتم معاملة نقل البيانات و كل شيء.هنا لقد استعملت "أنا موجود" القدرة على إسقاط الأوامر لجعل التراجع القسم سعيدا حتى عندما يكون التغيير غير المطبقة.Istr شيء واحد فعلنا في العمل Oracle كتابة التغييرات المخطط كما PL/SQL-هل يمكن أن يكون ربما بعض الوظائف في plpgsql للمساعدة في إجراء التغييرات ؟

علما أنه في تغيير أعلاه ، أين أنا ترحيل "العرض" و "الطول" الأعمدة (التي كانت nullable) من "موقع" مستقل "location_coordinates" العلاقة (و إضافة في earthdistance الاشياء) لم إسقاط الأعمدة القديمة.شيء واحد يجب أن تكون حذرا من جعل التغييرات المخطط إلى الوراء متوافقة إذا كان ذلك ممكنا.لذلك لا يمكن تطبيق هذا المخطط تغيير قبل تحديث التطبيق إلى استخدام جداول جديدة.يجب تغيير الثاني إلى إسقاط الأعمدة القديمة لتطبيق بعد تحديث التطبيق.في العمل هذه سوف يتم في دورات الإفراج عنهم ، حتى أثناء إطلاق X لا يزال لدينا الاختياري من دحر التطبيق إلى الإصدار X-1 دون الحاجة إلى استرجاع جميع التغييرات المخطط الأول ؛ فضلا عن كونها قادرة على نشر التغييرات المخطط في نافذة منفصلة من قبل التطبيقات.(من الناحية الفنية يجب أن يكون مكتوب على الزناد حتى تحديثات الجدول القديم يتم مزامنتها إلى جدول جديد ، ولكن لم لأن هذا هو مثل الكثير من العمل :))

لدينا أيضا أشياء مثل تطبيق العناكب جميع قواعد البيانات لمعرفة ما هو في schema_version الجدول المسارات التغييرات حتى يتمكن الناس حتى ترى ما هي التغييرات التي تم إجراؤها دون الحاجة للاتصال والحصول على فكرة عن تاريخ كل تغيير (نحن تتبع "التراجع في ديف", "تطبيقها في ديف" إلخ).في العمل لدينا schema_version الجدول يتضمن أيضا التأليف المعلومات وما إلى ذلك.طريقة سحرية من تطبيق معلومات الإصدار من التحكم في الإصدار سيكون بارد - مشكلة واحدة لدينا هو أنه إذا كان SC يحصل تطبيقها في سؤال وجواب ، على سبيل المثال ، ثم تغيرت في قهرا, ربما لا أحد الإشعارات.حتى طريقة لتتبع أن تغيير المخطط 35 تنقيح #4 هو تطبيق من شأنها أن تكون جيدة.

شيء واحد أن نلاحظ - التغييرات المخطط بالنسبة لنا هي مرقمة بشكل مستقل من إصدارات التطبيق.من الواضح أنها ترتبط--- هذا هو آخر شيء spidering التطبيق يسمح للناس بالدخول--- ولكن نحن نحاول أن لديك الكثير من التغييرات الصغيرة بدلا من عملاق "هنا كل شيء عن الإصدار X" التصحيح.التغييرات المخطط كما تستخدم أشياء مثل إضافة مؤشرات جديدة ، لذلك قد لا يكون التطبيق يحركها في كل شيء.في عام التغييرات المخطط "يملكها" من قبل المطورين ، لا دباس - على الرغم من أن في "إنشاء فهرس" في المثال أعلاه ، DBA هو في الأساس يتصرف في المطور دور امتلاك تغيير المخطط.نعم نحن نصر على مستوى عال من SQL قدرة من المطورين - على الرغم من أن مجموعات أخرى في الشركة تعمل بشكل مختلف قليلا وإعطاء المزيد من العمل إلى DB الفريق.