คุณจัดการมิติฐานข้อมูลที่เปลี่ยนแปลงตลอดเวลาอย่างไร

9

ในช่วงสองเดือนที่ผ่านมาฉันกำลังมองหาโซลูชันหรือแนวทางปฏิบัติเพื่อจัดการการจัดการการเผยแพร่ภายในฐานข้อมูล ฉันกำลังมองหาสิ่งที่ผู้คนมองว่าเป็นกระบวนการที่ดีที่สุดในการจัดการสิ่งนี้

เรามี 3 สภาพแวดล้อมสำหรับฐานข้อมูลของเรา:

พัฒนาการ
การทดสอบการยอมรับของผู้ใช้ (UAT)
การผลิต

ปัญหาคือบางครั้งเรากำลังเปลี่ยนแปลงสิ่งต่าง ๆ ภายในฐานข้อมูลการพัฒนาของเราและเวลาในการปรับใช้คุณสมบัติบางอย่างอาจไม่พร้อมที่จะนำไปใช้กับ UAT

เมื่อเร็ว ๆ นี้เราได้เริ่มใช้การควบคุมแหล่งที่มาของ Red Gate SQL สำหรับการจัดเก็บเอนทิตีทั้งหมดของเรา

ฉันคิดว่าจะไปตามชุดการเปลี่ยนแปลง (เช่นบอกว่าทุกอย่างจากเซ็ตการแก้ไข X และตอนนี้กลับถูกผลักไปที่ UAT) อย่างไรก็ตามนี่หมายความว่าผู้คนกำลังตรวจสอบรหัสของพวกเขาในการควบคุมซอร์สก่อนที่เราจะปรับใช้ซึ่งทำให้เกิดความสับสน โดยเฉพาะอย่างยิ่งเมื่อคนลืม) ปัญหาอีกประการหนึ่งที่เกิดขึ้นกับวิธีเซ็ตการแก้ไขคือหากมีข้อผิดพลาดในขั้นตอนการจัดเก็บที่จำเป็นต้องแก้ไขหมายเลขเซ็ตการแก้ไขจะจบลงด้วยการไม่อยู่ในขอบเขตของเซ็ตการแก้ไขสูงสุดของเราสำหรับการแก้ไขดังนั้น สร้างฐานข้อมูลใหม่จากเซ็ตการแก้ไขสูงสุดเราจะผลักดันข้อผิดพลาดออกไปอีกครั้ง

ข้อเสนอแนะใด ๆ เกี่ยวกับกระบวนการ?

ขอบคุณ

— judda
แหล่งที่มา

ดูเหมือนว่าสคริปต์ฐานข้อมูลของคุณไม่ได้อยู่ในแหล่งควบคุมเดียวกันกับรหัส "ของจริง" ของคุณ ทำไมนี้ คุณสามารถปฏิบัติต่อมันเป็น "ซอร์สโค้ด" และวางมันกับแต่ละสาขาได้หรือไม่?

— Mike M.

ขณะนี้เราเก็บเฉพาะเวอร์ชันการพัฒนาของสคริปต์ในการควบคุมแหล่งที่มาและ UAT / การผลิตทั้งคู่ขาดการซิงค์กับการพัฒนาที่ใช้งานอยู่ สคริปต์แต่ละตัวในการควบคุมซอร์สถูกอัพเดตทุกครั้งที่ผู้พัฒนาทำการคอมมิท ปัญหาของแต่ละสาขาคือเรามีฐานข้อมูลส่วนกลาง 1 ฐานที่ทุกคนใช้ (สำหรับการเปลี่ยนแปลงที่ใหญ่กว่า

1

คุณสามารถสร้างสาขาสำหรับการเปิดตัวและกระทำการเปลี่ยนแปลงที่เกี่ยวข้องกับการเปิดตัวเท่านั้น การเปลี่ยนแปลงอื่น ๆ ทั้งหมดควรทำกับลำตัว คุณต้องการฐานข้อมูลการพัฒนาสองฐาน นี่จะเป็นปัญหาหรือไม่?

เสียงที่ดูเหมือนว่ามีแนวโน้มที่จะล้าสมัยอย่างรวดเร็ว ไม่มี? สำหรับหนึ่งในโครงการของฉันเราอยู่ในช่วงกลางของการยกเครื่องขนาดใหญ่ของฐานข้อมูลดังนั้นเราจึงแยกสาขาออกไปเพื่อให้การพัฒนาที่แอคทีฟยังคงเกิดขึ้นในฐานข้อมูลเวอร์ชันที่ไม่มีการแก้ไข อย่างไรก็ตามในแต่ละวันฉันเห็นว่าเวอร์ชันแยกย่อยของเราเริ่มล้าสมัยมากขึ้นเรื่อย ๆ ซึ่งฉันไม่แน่ใจว่ามันโอเคหรือไม่ ... ฉันไม่เคยจัดการกับสถานการณ์เช่นนี้มาก่อน

— judda

5

การโยกย้าย

ขึ้นและลงที่อยู่ใน repo ของคุณและติดแท็กพร้อมกับแอพของคุณ

คุณยังสามารถ DIY กับไฟล์ flatfiles sql ที่ปรับเปลี่ยน schema ของคุณและปรับปรุงเวอร์ชั่นของ schema สิ่งที่คุณต้องทำคือ:

รักษาการย้ายข้อมูลของคุณไว้ถัดจากซอร์สโค้ดซึ่งควรเป็นเวอร์ชันและติดแท็กด้วยกัน
ใช้การเปลี่ยนแปลงที่มีการจัดการ (การย้ายข้อมูล) ในทุกสภาพแวดล้อมเสมอ
ไม่อนุญาตให้มีการดัดแปลง Ad-hoc ในสภาพแวดล้อมใด ๆ

คุณสามารถทำการเปลี่ยนแปลงการพัฒนาใน dev แต่คุณควรทำให้คุณหายไปและสร้างมันใหม่ด้วยการย้ายข้อมูลเมื่อคุณบันทึกการเปลี่ยนแปลง

— dietbuddha
แหล่งที่มา

จะเกิดอะไรขึ้นหากพบข้อบกพร่องในสคริปต์ คุณกลับไปที่สคริปต์ sql และอัปเดตหรือไม่

— judda

1

ไม่คุณสร้างการย้ายข้อมูลใหม่ (ซึ่งจะเป็นการเพิ่มเวอร์ชันสกีมา) นั่นคือวิธีที่คุณทราบว่าโปรแกรมฟิกซ์ถูกปรับใช้โดยดูที่เวอร์ชันสกีมาในฐานข้อมูล

— dietbuddha

ขอขอบคุณสำหรับความช่วยเหลือของคุณ. จากภาพรวมครั้งแรกสิ่งนี้ดูเหมือนจะเป็นแนวทางที่แข็งแกร่งและคล้ายกับกลยุทธ์การแยกสาขาของเรา

— judda

2

การควบคุมแหล่งที่มา!

คุณไม่ปรับใช้ไบนารีการพัฒนาของคุณโดยตรงกับการผลิตโดยไม่ต้องผ่าน svn / git / p4 ดังนั้นทำไมฐานข้อมูลของคุณถึงทำเช่นนั้น? รับอินสแตนซ์ส่วนตัวสำหรับนักพัฒนาเพื่อทดสอบการเปลี่ยนแปลงในเครื่องของพวกเขา แต่เมื่อต้องไปที่ฐานข้อมูลการพัฒนาจะต้องดำเนินการผ่านไฟล์ที่ตรวจสอบใน ddl คุณสามารถเขียนเครื่องมือเพื่อใช้การเปลี่ยนแปลง ddl เหล่านี้โดยอัตโนมัติ (ฉันไม่รู้วิธีที่มีอยู่ในการทำสิ่งนี้อย่างถูกต้อง)

เมื่อคุณมีข้อ จำกัด เกี่ยวกับการเปลี่ยนแปลง db schema ในสถานที่ (ไม่มี sqlplus เพิ่มเติม -> ปัญหา ddl!) และมีการควบคุมบัญชีที่เข้มงวด (ไม่มีการเข้าถึง ddl สำหรับทุกคน) สิ่งนี้ควรจัดการได้ง่าย

— Subu Sankara Subramanian
แหล่งที่มา

1

น่าเศร้าที่ฐานข้อมูลของเรามีขนาดใหญ่เกินไปที่จะส่งต่อระหว่างผู้พัฒนาเพื่อให้เซสชันส่วนตัวทำงาน เช่นเดียวกับที่ดูเหมือนจะไม่เอนเอียงไปสู่การพัฒนาโดยใช้ทีมมากขึ้นเพราะ ณ ตอนนี้ฉันทำการพัฒนาในขณะที่พูดคุยกับผู้คนสำหรับงาน UI ที่เชื่อมโยงทั้งสอง ฉันจะต้องเริ่มต้นด้วยการตรวจสอบการเปลี่ยนแปลงทั้งหมดแล้วให้พวกเขาได้รับข้อมูลล่าสุดบนฐานข้อมูลซึ่งดูเหมือนจะเป็นเรื่องที่ค่อนข้างยุ่งยาก

— judda

เหตุใดการพัฒนาฐานข้อมูลของคุณจึงต้องมีขนาดเท่ากันกับฐานข้อมูลการผลิต พวกเขาสามารถมีสคีมาเดียวกันและคุณยังสามารถมีกองทดสอบพิเศษที่มีข้อมูลทั้งหมด แต่ฐานข้อมูล dev ท้องถิ่นอาจมีขนาดเล็ก สิ่งนี้ยังช่วยป้องกันปัญหาการรั่วไหลของข้อมูลเป็นต้น - ในทางทฤษฎีแล้วข้อมูลการผลิตไม่ควรพัฒนาเลย

— Subu Sankara Subramanian

ข้อมูลทั้งหมดของเราถูกโหลดผ่านกระบวนการโหลดข้อมูลซึ่งประมวลผลไฟล์ที่เราได้รับจากลูกค้าแล้วแปลงเป็นข้อมูลที่เราต้องการ ดังนั้นจึงเป็นไปไม่ได้ที่เราจะแยกข้อมูล dev และ prod ที่ได้รับจากการโหลดข้อมูลทั้งหมดจะต้องได้รับการตรวจสอบในการพัฒนาต่อไป ฉันเดาว่ามันไม่จำเป็นต้องมีขนาดเท่ากัน แต่ก็จำเป็นต้องใช้ข้อมูลจำนวนเท่ากันเพื่อรายงานที่เราสร้างขึ้นเพื่อสร้างข้อมูลที่มีความหมาย

— judda

ฐานข้อมูลทั้งหมดไม่จำเป็นต้องทำซ้ำ ใน Oracle ผู้ใช้ทุกคนมีสคีมาของตนเองและเรามีสคีมาของแอปพลิเคชันเดียว สร้างคำพ้องความหมายสาธารณะสำหรับวัตถุทั้งหมดในสคีมาของแอปพลิเคชัน จากนั้นผู้ใช้ทุกคนสามารถเปลี่ยนวัตถุ (tables, SPs) ใน schema ของตนเองและหากพวกเขาเชื่อมต่อด้วยตนเองพวกเขาจะใช้ชื่อวัตถุ สำหรับวัตถุที่ไม่ได้อยู่ในสคีมานั้นจะใช้คำพ้องความหมาย woukd นี่คือวิธีที่เราทำงาน

— softveda

0

ติดตามข้อเสนอแนะของการใช้การย้ายข้อมูล ... อาจใช้ O / RM ที่สนับสนุนการย้ายข้อมูลเช่น Ruby on Rails และ Entity Framework 4.3 ปัญหาเกี่ยวกับวิธีการทั้งสองวิธีอย่างไรก็ตามการโยกย้ายนั้นทั้งหมดหรือเปล่า คุณไม่สามารถเลือกได้ว่าจะใช้การโยกย้ายแบบใดในแง่ของชุดการเปลี่ยนแปลง

อีกตัวเลือกที่ทำงานได้ (ถ้าคุณอยู่ใน microsoft stack คุณไม่เคยพูดถึงแพลตฟอร์ม) คือการจัดการ SQL ของคุณด้วยเครื่องมือฐานข้อมูล Visual Studio มันได้สร้างขึ้นใน refactoring (เปลี่ยนชื่อ / ลบคอลัมน์ ฯลฯ ) และทำการตรวจสอบรูปแบบ ตัวอย่างเช่น proc ที่เก็บไว้อ้างอิงคอลัมน์ที่ไม่มีอีกต่อไปมันจะแจ้งให้คุณทราบ

— Michael Brown
แหล่งที่มา