คุณควรออกแบบฐานข้อมูลก่อนที่จะเขียนรหัสแอปพลิเคชันหรือไม่

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

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

จากประสบการณ์ของคุณสิ่งใดที่คุณคิดว่าเป็นวิธีที่มีประสิทธิผลและมีประสิทธิภาพมากที่สุด

นอกจากคำตอบอื่น ๆ ...

การจับแบบจำลองแนวคิดของคุณก่อนควรกำหนดขอบเขตและข้อกำหนด จากสิ่งนี้คุณสามารถสืบทอดโมเดลข้อมูลโลจิคัลและฟิสิคัลของคุณ

ครั้งนี้เป็นส่วนใหญ่คงที่แล้วคุณมีฐานข้อมูลที่มั่นคงเพื่อสร้างใบสมัครของคุณกับ นี่ตรงกันข้ามกับตัวเลือกแรกของคุณ

จุดที่สองของคุณจะจบลงด้วยโคลนที่ยุ่งเหยิงและไม่สามารถรักษาได้ รูปแบบข้อมูลจะไม่ได้รับการแก้ไข: ถ้าคุณไม่ได้ออกแบบไว้ล่วงหน้าคุณจะไม่มีเวลาแก้ไขก่อนที่จะส่ง คุณจะยุ่งเกินไปกับการแฮ็คสิ่งต่างๆเข้าด้วยกัน

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

คุณจะกดยากที่จะค้นหาแผนกซอฟต์แวร์ที่ทันสมัยซึ่งไม่ได้ทำงานกับ Agile บางรุ่น การเปรียบเทียบของ DBA นั้นติดอยู่ในยุคมืดด้วยความคิดที่ว่า @ RobPaller มีคำตอบอยู่ทั่วไป

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

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

ฉันเดาว่าจะทำให้การลงคะแนนของฉันกับตัวเลือกของคุณ 2 และฉันสงสัยว่าฉันอาจพบว่าตัวเองกำลังยืนอยู่บนความหนาวเย็นในรายการนี้!

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

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

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

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

หวังว่านี่จะช่วยได้

ฉันมีความหรูหราในการออกแบบฐานข้อมูลขนาดกลางที่มีความซับซ้อนหลายอย่างซึ่งทั้งหมดใช้ในธุรกิจโดยมีส่วนหน้าส่วนต่าง ๆ รวมถึงเว็บ Access และ C #

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

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

ระบบที่ฉันสร้างมักจะอยู่ในพื้นที่ใหม่ที่ไม่มีใครเข้ามาก่อน ฉันไม่มีการบายอินจากองค์กรทรัพยากรหรือเครื่องมือในการทำงานกับทีมพัฒนาของนักออกแบบมืออาชีพด้านการบินที่สามารถจ่ายเงินเป็นทีมได้สิบครั้งสิ่งที่ฉันสร้างเพื่อสร้างสิ่งต่าง ๆ ใน สองครั้ง

ฉันดีในสิ่งที่ฉันทำ แต่มีเพียงฉันคนเดียวที่ทำได้ในสภาพแวดล้อมที่ "ไม่พัฒนา"

จากทั้งหมดที่กล่าวมาฉันเริ่มดีขึ้นในการค้นหากฎเกณฑ์ทางธุรกิจ และฉันเห็นตัวเลือกที่สาม:

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

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

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

ในความคิดของฉันนี่เป็นชัยชนะครั้งใหญ่

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

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

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

ในโลกของสถาปัตยกรรมวลี"Form Follows Function"ได้รับการประกาศเกียรติคุณและปฏิบัติตามในภายหลังเมื่อสร้างอาคารสูง ควรนำไปใช้กับโครงสร้างพื้นฐานของ DB และการพัฒนาแอปพลิเคชัน

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

แต่น่าเสียดายที่ร้านค้าของนักพัฒนาซอฟต์แวร์บางแห่งจะรับสินค้าเช่น memcached โหลดด้วย data ใน RAM (ดังนั้นถือว่าเป็นเหมือน data data) และมีฐานข้อมูลเช่น MySQL หรือ PostgreSQL ทำหน้าที่เป็นหน่วยเก็บข้อมูล

สิ่งจูงใจสำหรับการใช้ฐานข้อมูลควรดูอย่างเหมาะสม: เป็น RDBMS ใช่ระบบการจัดการฐานข้อมูลเชิงสัมพันธ์ เมื่อคุณใช้ RDBMS เป้าหมายล่วงหน้าของคุณไม่เพียง แต่จะต้องสร้างตารางสำหรับการจัดเก็บ แต่ยังสำหรับการดึงข้อมูล ความสัมพันธ์ระหว่างตารางควรเป็นตัวอย่างหลังจากข้อมูลที่คุณต้องการดูและวิธีการนำเสนอ สิ่งนี้ควรอยู่บนพื้นฐานของความสอดคล้องและความถูกต้องของข้อมูลพร้อมกับกฎเกณฑ์ทางธุรกิจที่เป็นที่รู้จัก กฎเกณฑ์ทางธุรกิจเหล่านั้นสามารถเขียนในแอปของคุณ (Perl, Python, Ruby, Java, ฯลฯ ) หรือในฐานข้อมูล

สรุปผลการศึกษา

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

ฉันคิดว่าควรทำก่อนที่จะมีรหัสจริงสำหรับแอปพลิเคชัน แต่ไม่ควรทำก่อนที่แอปพลิเคชันจะได้รับการออกแบบ

เวิร์กโฟลว์ทั่วไปของฉันหากทำงานคนเดียวคือ:

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

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

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

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

ฉันมีกฎ follwing: "คุณจะได้รับจากฐานข้อมูลข้อมูลที่คุณมีข้อมูลที่จะสร้าง" ดังนั้นฉันจะออกแบบฐานข้อมูลก่อนรหัสในภายหลัง

ทำไม? ไม่ว่าฉันใช้ metodology / ภาษา / ชุดเครื่องมือใด ๆ หากข้อมูลที่เกี่ยวข้องทั้งหมดได้รับการออกแบบมาอย่างดีและเก็บไว้ใน DB I สามารถเรียกใช้ได้ ไม่ว่าจะอยู่ใน C # / Delphi / FORTRAN / COBOL / Assembly / VBA หรือรายงาน Crystal; OO ออกแบบหรือเหตุการณ์ / ข้อมูล / สิ่งที่ขับเคลื่อน; เปรียวหรือน้ำตก หากมีข้อมูลอยู่ฉันสามารถดึงข้อมูลได้หากเครื่องมือที่ฉันใช้สามารถเชื่อมต่อกับฐานข้อมูล ฉันสามารถสร้างรายงานการขายได้ถ้าฉันสามารถเลือกคำสั่งซื้อสำหรับรายรับรายไตรมาส - แม้ว่าฉันจะต้องเขียนมันทีละไบต์ในสภา

หากข้อมูลที่เกี่ยวข้องไม่ได้อยู่ที่นั่นหรือแม้ว่าจะมี แต่ (ยกเลิก) โครงสร้างในวิธีที่ฉันไม่สามารถดึงข้อมูลที่ฉันต้องการ - วิธีการรหัสมัน?

ตามปกติมันขึ้นอยู่กับ;)

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

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