แนวทางปฏิบัติที่ดีที่สุดสำหรับการออกแบบฐานข้อมูลใหม่


24

ฉันตระหนักถึงแนวปฏิบัติที่ดีที่สุดทั่วไปบางอย่างเมื่อออกแบบฐานข้อมูลสำหรับแอปพลิเคชัน แต่สิ่งที่เกี่ยวกับการออกแบบใหม่?

ฉันอยู่ในทีมที่มอบหมายการออกแบบแอปพลิเคชันธุรกิจภายในใหม่ถึงแม้ว่าฉันจะพูดว่า "ภายใน" แต่ฉันก็ยังโชคร้ายที่มีคนจำนวนมากที่ไม่ได้ติดต่อกับผู้ใช้จริงของระบบ

โปรแกรมปัจจุบันอยู่ใน Oracle Forms ซึ่งกระจายอยู่ในตารางที่ไม่ได้ถูกทำให้เป็นมาตรฐานซึ่งบางครั้งมีตารางที่ใกล้เคียงกันหลายชุดซึ่งมีข้อมูลที่แตกต่างกันเล็กน้อย ข้อ จำกัด มักจะอยู่ในรูปแบบของขั้นตอนการจัดเก็บที่มีการบังคับใช้ไม่ดี แม้แต่ประเภทก็ดูเหมือนจะไม่ถูกจัดเก็บไว้อย่างถูกต้อง ฉันพบข้อมูลที่ไม่ดีทุกประเภทที่ Oracle ดูเหมือนว่าจะเพิกเฉย แต่ได้ให้ตัวช่วยสร้างการนำเข้าและส่งออกของ SQL Server (และถูกต้องแล้ว) (ตัวอย่างเช่นจำนวนเต็มสองหลักไม่ได้เป็นการ datetime ที่สมบูรณ์!)

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

ผลลัพธ์สุดท้ายของการเขียนซ้ำจะเป็นเวอร์ชั่นที่ทำงานบนเว็บที่ทำงานบน ASP.NET พร้อมกับ MS SQL Server สำหรับด้านหลัง

เพื่อนร่วมทีมนักพัฒนาซอฟต์แวร์อีกสองคนของฉันอายุมากกว่าฉันมากทั้งสองมีภูมิหลังทางธุรกิจ / MIS ในขณะที่ฉันเป็น CS ประสบการณ์ของสมาชิกอาวุโสนั้นเกือบจะเป็นรูปแบบของออราเคิลเท่านั้นและสมาชิกคนอื่น ๆ ส่วนใหญ่ได้ทำแอปพลิเคชันทางธุรกิจใน Visual Basic แม้ว่าพื้นหลังฐานข้อมูลของฉันจะถูก จำกัด ให้ออกแบบฐานข้อมูลใหม่สำหรับโครงการใน MySQL หรือ SQLite แต่ส่วนใหญ่สำหรับชั้นเรียนระดับปริญญาตรีของฉันฉันดูเหมือนจะเป็นคนเดียวที่มีประสบการณ์ในการออกแบบฐานข้อมูลจริง ๆ เลย

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

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


5
หากไม่มีทีมงานส่วนใหญ่ที่คุ้นเคยกับเทคโนโลยีใหม่โครงการจะไม่ประสบความสำเร็จ โปรไฟล์ทางเทคนิคปัจจุบันที่อธิบายไว้ไม่เหมาะสำหรับงานนี้
NoChance

2
ฉันเห็นด้วยกับ Emmad Kareem คุณขาดทักษะสำคัญบางอย่าง ดูเหมือนว่าทีมของคุณอาจขาดคนที่รู้จัก ASP.NET/C#, การออกแบบ SQL Server / DB และการออกแบบเชิงวัตถุในระดับที่คุณต้องดึงออกจากโครงการที่มีความทะเยอทะยาน
jfrankcarr

3
ฉันเห็นด้วยกับความคิดเห็น แต่ยังเป็น +1 ที่ยิ่งใหญ่สำหรับการมีทักษะในการเปิดเผยปัญหาของคุณอย่างชัดเจนยอมรับขีด จำกัด ของทักษะที่คุณกำหนดและค้นหาแนวทางปฏิบัติที่ดีที่สุด มันเป็นการเริ่มต้น
SRKX

คำตอบ:


23

ฉันคิดว่าคุณรู้วิธีทำให้ฐานข้อมูลเป็นมาตรฐาน

สิ่งที่คุณต้องการคือกลยุทธ์ในการลดความเสี่ยงเมื่อย้ายซอฟต์แวร์ทั้งหมดไปยังฐานข้อมูลใหม่

สิ่งที่ฉันแนะนำคือการทำงานมากกว่าเป็นการแลกเปลี่ยนเพื่อลดความเสี่ยง

ทำให้ฐานข้อมูลเป็นปกติและสร้างกระบวนการเพื่อเติมฐานข้อมูลที่ทำให้เป็นมาตรฐานด้วยข้อมูลจากฐานข้อมูลดั้งเดิม ฐานข้อมูลดั้งเดิมจะเป็นฐานข้อมูลสำหรับการแทรกการอัพเดทและการลบ ฐานข้อมูลปกติจะเป็นฐานข้อมูลแบบสอบถามในระหว่างการแปลงเท่านั้น

กระบวนการเติมข้อมูลของคุณจะต้องทำงานบ่อยเท่าที่ต้องการสำหรับข้อมูลแบบสอบถาม หากข้อมูลเก่าของวันนั้นเป็นที่ยอมรับคุณสามารถเรียกใช้กระบวนการเติมข้อมูลตอนกลางคืน หากคุณต้องการข้อมูลที่เป็นปัจจุบันมากขึ้นคุณจะต้องเรียกใช้กระบวนการเติมข้อมูลอย่างต่อเนื่อง

สร้างส่วนแบบสอบถามของระบบ ASP.NET ใหม่ของคุณชี้ไปที่ฐานข้อมูลปกติใหม่

ผลลัพธ์แบบสอบถามจากระบบใหม่ของคุณควรเปรียบเทียบกับผลลัพธ์แบบสอบถามจากระบบดั้งเดิม

คุณสามารถหยุดที่จุดนี้ เป็นการตัดสินใจทางธุรกิจไม่ใช่การตัดสินใจทางเทคนิค

ในยามว่างคุณสร้างฟังก์ชั่นแทรก / อัพเดต / ลบใหม่ในระบบ ASP.NET ใหม่ของคุณ ในขณะที่คุณสร้างฟังก์ชันการทำงานใหม่คุณจะปิดส่วนต่าง ๆ ของระบบดั้งเดิมที่สอดคล้องกัน ในบางจุดไม่มีระบบเดิมเหลืออยู่

ข้อดีของการแปลงในลักษณะนี้คือการลดความเสี่ยงโดยการสร้างส่วนของแบบสอบถามก่อน โดยทั่วไปแล้วฟังก์ชันคิวรี่นั้นง่ายกว่าเมื่อเปรียบเทียบกับตรรกะทางธุรกิจที่ฝังอยู่ในฟังก์ชันการแทรก / อัพเดต / ลบ

คุณสามารถแปลงฟังก์ชันการแทรก / อัพเดต / ลบได้ครั้งละหนึ่งกระบวนการ หากมีปัญหาเกี่ยวกับความเข้าใจผิดเกี่ยวกับตรรกะทางธุรกิจสามารถแก้ไขได้ในขณะที่ผู้ใช้กำลังใช้ระบบดั้งเดิม

ควรดำเนินการต่อโดยไม่บอกว่ากระบวนการเติมข้อมูลของคุณดีขึ้นอย่างสม่ำเสมอ


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

2

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

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


+1 สำหรับการตระหนักถึงความสำคัญของการมีทักษะที่ต้องการ
NoChance

น่าเสียดายที่เราเป็นผู้รับเหมา โปรแกรมเมอร์ทั้งหมดที่นี่คือ ทีมของเราเป็นผู้นำด้วยเช่นกัน แต่ที่ผ่านมานั้นผู้บังคับบัญชาของเราเป็นระบบการจัดการของลูกค้าหลายระดับ
UtopiaLtd

2

ออกแบบฐานข้อมูลปกติที่คุณต้องการด้วยประเภทข้อมูลที่คุณต้องการ จากนั้นส่วนที่ยากที่สุดคือการย้ายข้อมูล ก่อนอื่นคุณต้องมีแผนว่าคุณจะทำแผนที่อย่างไรจากแผนที่เก่าไปสู่ใหม่และสิ่งที่คุณจะทำกับข้อมูลที่ไม่ตรงกับโครงสร้างใหม่ ตัวอย่างเช่นคุณอาจมีข้อมูลคือตอนนี้ไม่สามารถระบุได้ถ้าคุณไม่มีข้อ จำกัด ด้านความสมบูรณ์ คุณอาจไม่ต้องการย้ายข้อมูลนั้นหรือคุณอาจต้องการย้าย แต่แนบไปกับระเบียนหลักใหม่ที่เรียกว่า "ไม่ทราบ" หากวันที่ไม่ใช่วันที่จริงคุณสามารถใส่ค่าเป็นศูนย์ในการย้ายข้อมูลได้หรือไม่? คุณจะต้องตอบคำถามเหล่านั้น ฉัน woudl แนะนำว่าคุณมีนักพัฒนาบางคนทำงานเกี่ยวกับการเปลี่ยนแปลง gui เพื่อใช้ struture ฐานข้อมูลใหม่และอื่น ๆ เพื่อทำงานอย่างเคร่งครัดในการโยกย้าย การโยกย้ายเป็นงานที่ยิ่งใหญ่ มันจะใช้ทักษะและเวลามากมาย อย่าปล่อยให้มันเป็นภายหลัง

เนื่องจากคุณใช้ SQL Server คุณสามารถทำการโยกย้ายจริงผ่าน SSIS

สร้างชุดทดสอบที่ดีเพื่อให้คุณสามารถเปรียบเทียบว่าผลลัพธ์กับระบบเก่าเหมือนกันกับระบบใหม่

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


1

ฉันเผชิญหน้ากับการออกแบบ schema ของฐานข้อมูลใหม่เกือบทุกวันเนื่องจากการสนับสนุนและการพัฒนาเพิ่มเติมของแอปพลิเคชันรุ่นเก่าที่เกิดขึ้นเป็นไฟล์ MS Access (.mdb) จากนั้นเติบโตขึ้นเป็นฐานข้อมูลขนาดใหญ่ด้วยตารางหลายร้อยใน MS SQL เซิร์ฟเวอร์ แต่ยังคงมี "ทารกตาย" ของการออกแบบเดิม นี่คือวิธีปฏิบัติบางอย่างที่ฉันพบว่ามีประโยชน์สำหรับฉัน:

พยายามย่อส่วนพื้นผิวที่เปิดเผยต่อสาธารณะของสกีมาฐานข้อมูลของคุณ

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

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

พยายามปรับให้เหมาะสมสำหรับเกณฑ์ในโลกแห่งความเป็นจริงไม่ใช่สำหรับหนังสือที่มาจาก

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

บันทึกเซสชันการทำโปรไฟล์และวิเคราะห์

การออกแบบฐานข้อมูลใหม่โดยยึดตามสคีมาฐานข้อมูลเพียงอย่างเดียวนั้นไม่สมบูรณ์ ดูฐานข้อมูลของคุณในพลวัตพยายามค้นหาคอขวดระหว่างการทดสอบโหลดและจัดการกับสิ่งเหล่านั้น ในกรณีของ MS SQL Server จะมีโปรแกรมช่วยแนะนำการปรับแต่งพิเศษที่สามารถสร้างคำแนะนำบางอย่างจากการติดตามกิจกรรมที่บันทึกไว้


0

นี่คือคำตอบของฉัน:

  1. ก่อนอื่นให้ทำความเข้าใจระบบฐานข้อมูลปัจจุบันให้มากที่สุด คุณจำเป็นต้องรู้การใช้งานทั้งหมดของระบบเหล่านี้รวมถึงผู้ใช้ คุณจำเป็นต้องทราบแหล่งที่มาทั้งหมดไปยังระบบเช่นเดียวกับระบบที่อาจทำหน้าที่เป็นระบบแหล่งที่มา

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

  3. วิเคราะห์และทำความเข้าใจกระบวนการ ETL ปัจจุบันที่โหลดข้อมูลไปยังฐานข้อมูลและดึงข้อมูลจากฐานข้อมูล

  4. ทำความเข้าใจองค์ประกอบข้อมูลทั้งหมดของฐานข้อมูลและหากคุณสามารถสร้างเมทริกซ์กล่องซึ่งสามารถช่วยคุณระบุองค์ประกอบที่ซ้ำกัน

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

  6. โชคดี!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.