काम पर, SQL सर्वर के लिए, हम स्कीमा परिवर्तन स्क्रिप्ट लिखते हैं जो पहले बदलाव को वापस रोल करते हैं (बेवकूफ रूप से, इसलिए रोलबैक अनुभाग ठीक चलाता है भले ही स्कीमा परिवर्तन अभी लागू नहीं हुआ हो), और फिर एक सेक्शन परिवर्तन लागू करने के लिए। टीएसक्यूएल में सिस्टम कैटलॉग या अन्य तालिकाओं में यह देखने के लिए आसान है कि टेबल/कॉलम/इंडेक्स/पंक्तियां पहले से मौजूद हैं या नहीं, और कुछ भी नहीं करें।
पोस्टग्रेएसक्यूएल में, आप कुछ और बाध्य हैं जो आप सर्वर पर आसानी से भेज सकते हैं - लेकिन दूसरी तरफ, डीडीएल लेनदेनपूर्ण है, इसलिए आधा-लागू स्कीमा परिवर्तन नहीं होना चाहिए। मैंने अपनी छोटी परियोजनाओं पर बहुत अच्छी तरह से उपयोग करने के लिए काम पर उपयोग की जाने वाली योजना को अनुकूलित किया है (ओवरकिल? लेकिन यहां तक कि यहां मेरे पास एक dev/test 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 schema-change/35.sql" के साथ चलाया जा सकता है। "आवेदन करने ..." संदेश को काटकर, मैं इसे वापस रोल करने के लिए आदेश प्राप्त कर सकता हूं। और जैसा कि आप देख सकते हैं, परिवर्तन मेटाडेटा तालिका "schema_version" को बनाए रखता है, इसलिए मैं देख सकता हूं कि कौन से परिवर्तन लागू होते हैं। संपूर्ण परिवर्तन लेनदेन, डेटा माइग्रेशन और सभी के रूप में किया जाता है। यहां परिवर्तन को अनुपयुक्त होने पर भी रोलबैक सेक्शन को खुश करने के लिए मैंने डीओआरपी कमांड की "अगर एक्सस्ट्स" क्षमता का उपयोग किया है। Istrcle के लिए काम पर हमने जो कुछ किया था, वह पीएल/एसक्यूएल के रूप में स्कीमा परिवर्तन लिख रहा था - क्या आप परिवर्तन करने में मदद के लिए शायद plpgsql में कुछ फ़ंक्शन कर सकते हैं?
ध्यान दें कि ऊपर दिए गए परिवर्तन में, जहां मैं "स्थान" से "अक्षांश" और "रेखांश" कॉलम (जो शून्य नहीं था) को "अलग-अलग" location_coordinates "संबंध (और धरती की सामग्री में जोड़ना) में माइग्रेट कर रहा हूं , मैंने पुराने कॉलम नहीं छोड़े। एक चीज जिसे हमें सावधान रहना है, स्कीमा को पीछे की तरफ बदलना है-यदि संभव हो तो संगत। तो मैं इस स्कीमा परिवर्तन से पहले नई टेबल का उपयोग करने के लिए ऐप अपडेट कर सकता हूं। ऐप को अपडेट करने के बाद लागू करने के लिए पुराने कॉलम ड्रॉप करने के लिए मेरे पास दूसरा परिवर्तन होगा। काम पर, ये दो अलग-अलग रिलीज चक्रों में किए जाएंगे, इसलिए रिलीज एक्स के दौरान हमारे पास अब भी सभी स्कीमा परिवर्तनों को वापस रोल किए बिना एक्स -1 जारी करने के लिए ऐप को रोल करने का विकल्प है; साथ ही ऐप्स से पहले एक अलग विंडो में स्कीमा परिवर्तनों को तैनात करने में सक्षम होने के नाते। (तकनीकी रूप से मुझे एक ट्रिगर लिखा जाना चाहिए था ताकि पुरानी तालिका में अपडेट नई तालिका में सिंक हो जाएं, लेकिन मेरे पास ऐसा नहीं है क्योंकि यह काम की तरह बहुत अधिक है :))
हमारे पास एक ऐसे एप्लिकेशन की तरह चीजें हैं जो हमारे सभी मकड़ियों यह देखने के लिए डेटाबेस schema_version तालिका में क्या है, और परिवर्तनों को ट्रैक करता है, इसलिए लोग यह भी देख सकते हैं कि कनेक्ट किए बिना क्या परिवर्तन किए गए थे, और प्रत्येक परिवर्तन के इतिहास का विचार प्राप्त करें (हम "देव में वापस लुढ़का" ट्रैक करते हैं, "इसमें लागू देव "आदि)।काम पर हमारी स्कीमा_वर्जन टेबल में लेखांकन जानकारी भी शामिल है। संस्करण नियंत्रण से संस्करण जानकारी लागू करने का एक जादू तरीका अच्छा होगा- हमारे पास एक समस्या यह है कि यदि एससी में एक अनुसूचित जाति लागू होती है, तो उदाहरण के लिए, फिर पर्सफोर्स में बदल दिया जाता है, शायद नहीं नोटिस तो उस स्कीमा परिवर्तन को ट्रैक करने का एक तरीका 35 संशोधन # 4 लागू किया गया था अच्छा होगा।
ध्यान देने योग्य एक बात- हमारे लिए स्कीमा परिवर्तन आवेदन संस्करणों से स्वतंत्र रूप से गिने जाते हैं। जाहिर है कि वे संबंधित हैं --- यह एक और चीज है जो स्पाइडरिंग ऐप लोगों को प्रवेश करने की इजाजत देता है --- लेकिन हम "विशाल रिलीज एक्स के लिए सबकुछ है" पैच के बजाय बहुत सारे छोटे बदलाव करने की कोशिश करते हैं। स्कीमा परिवर्तनों का उपयोग नए सूचकांक जोड़ने जैसी चीजों के लिए भी किया जाता है, इसलिए शायद ऐप-संचालित नहीं हो सकता है। आम तौर पर, स्कीमा परिवर्तन डेवलपर्स द्वारा "स्वामित्व" होते हैं, डीबीए नहीं - हालांकि ऊपर "इंडेक्स बनाएं" उदाहरण में, डीबीए मूल रूप से डेवलपर भूमिका में कार्य कर रहा है और स्कीमा परिवर्तन का मालिक है। हां, हम डेवलपर्स से उच्च स्तर की एसक्यूएल-क्षमता पर जोर देते हैं- हालांकि कंपनी के अन्य समूह थोड़ा अलग तरीके से काम करते हैं और डीबी टीम को और अधिक काम देते हैं।
धन्यवाद aragnid। हमारी कंपनी में भी, डेवलपर्स भूमिकाओं में उचित स्कीमा पैच भी शामिल हैं। वास्तव में पैच को संसाधित करने के लिए एक एकल प्रक्रिया का उपयोग किया जाता है। मुझे स्कीमा_वर्जन टेबल का विचार पसंद है, हमने चर्चा की थी कि मेरे कार्यस्थल पर, और आप इसे देखने के साथ-साथ इसे भी मान्य करते हैं। – chadl