มีความหวังในการเขียนรหัสที่ดีบนฐานข้อมูลที่ออกแบบมาอย่างน่ากลัว?


18

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

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

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

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

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


2
แค่คิดว่าคุณจะใช้รหัสอย่างไรกับห้องสมุดที่กรณีพิเศษ "2 + 2" ไม่ส่งคืน 4 มันไม่ใช่เรื่องง่าย

8
ดังนั้นสิ่งที่ฉันได้ยินทั้งหมดนี้คือคุณมีเวลา 30 วันในการหางานใหม่ ลองใช้งาน careers.stackoverflow.com ;-)
Steven A. Lowe


@gnat: ไม่ได้ปิด
Robert Harvey

คำตอบ:


27

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

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

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


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

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

3
@maple_shaft ตกลง แต่ OP บอกว่าเขาถูกขอให้สร้างตั้งแต่เริ่มต้นแอปพลิเคชันใหม่ที่จะโต้ตอบกับฐานข้อมูล ในกรณีเช่นนี้การสร้างแอปพลิเคชั่นใหม่นั้นเหมาะสม
Wayne Molina

1
@maple_shaft ส่วนอึเพียงส่วนเดียวของแอปพลิเคชันจะเป็นส่วนที่โต้ตอบกับฐานข้อมูลอึ นั่นคือจุดของสถาปัตยกรรม N-Tier และ SOC
StuperUser

1
@maple_shaft เป้าหมายจะทำให้ฐานข้อมูลเป็น "กล่องดำ" แปลก ๆ และให้แอปพลิเคชั่นอินเทอร์เฟซที่เหมาะและไม่จำเป็นต้องเป็นตัวแทนของการออกแบบฐานข้อมูล
Michael Dean

10

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


คุณจะลบคำตอบของคุณเองหรือไม่เป็นไปได้?
Ominus

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

@Ominus: มันควรจะเป็นไปได้ แต่ทำไมคุณต้องการที่จะ? คุณมี 3 upvotes!
FrustratedWithFormsDesigner

1
@Marjan: ผู้ดูแลและทุกคนที่มี> 10K rep
Jerry Coffin

1
ทำไมคุณต้องการลบคำตอบนี้ ฉันคิดว่ามันเป็นทางออกที่ยอดเยี่ยม
Jim G.

6

อุ๊ย ... คุณได้รับสิ่งที่เป็นฝันร้ายคุณมีเวลา 30 วันในการทำให้องค์กรของคุณใช้งานได้และครึ่งวันของคุณจะถูกนำไปใช้กับภารกิจการดำเนินงาน?

ฉันแน่ใจว่าคุณสามารถ refactor แต่ไม่แน่นอนในเวลานั้น

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

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


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

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

1
@ จอห์นนี่เป็นสิ่งที่ดีที่พวกเขาตระหนักถึงความจำเป็นในการปรับโครงสร้าง มันเป็นสัญญาณของการจัดการที่ดีในระยะยาวและขั้นตอนแรกในการปรับโครงสร้างใหม่
maple_shaft

3
+1 สำหรับคำตอบที่ยอดเยี่ยมและสมจริง คุณมีเดือน แต่จริง ๆ เพียงครึ่งเดือนเพราะคุณทำงานครึ่งเวลาในการดำเนินงาน นั่นคือ 11-15 วันขึ้นอยู่กับว่าคุณจะหยุดวันหยุดสุดสัปดาห์หรือไม่ ฉันเกลียดที่จะพูด แต่ฉันยอมรับว่าทางออกที่ดีที่สุดของคุณคือการรวมสิ่งที่ใช้งานได้โดยเร็วและจดบันทึกเกี่ยวกับวิธีปรับปรุงหรือเขียนใหม่ในภายหลัง
Bob Murphy

6

ฐานข้อมูลสามารถ refactored เช่นเดียวกับรหัสอื่น ๆ แก้ไขส่วนที่ได้รับผลกระทบจากรหัสที่คุณต้องใช้ในการเขียนและทดสอบเพื่อให้แน่ใจว่าไม่มีอะไรแตก ทำทีละน้อย ๆ เช่นเดียวกับการปรับโครงสร้างอื่น ๆ มีหนังสือที่ดีเกี่ยวกับการปรับโครงสร้างฐานข้อมูลที่อาจช่วยให้คุณเริ่มต้นในการทำความสะอาด http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

มีคนอื่นด้วยเช่นกัน แต่ส่วนตัวแล้วฉันได้อ่านและทำงานกับเทคนิคในอันนี้

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


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

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

+1 @HLGEM นี่เป็นจุดที่ดี คำแนะนำของคุณจะดีถ้ารหัสแอปพลิเคชันออกแบบมาอย่างดี การปรับโครงสร้างในส่วนต่างๆอาจเป็นวิธีที่ดีที่สุดที่จะไป แต่ในอาชีพการงานทั้งหมดของฉันฉันไม่เคยเห็นงานที่ประสบความสำเร็จ อาจเป็นเพราะการจัดการโครงการไม่ดี แต่ไม่ใช่เพราะมันเป็นแนวคิดที่ไม่ถูกต้อง
maple_shaft

5

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


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

4

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

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

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

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


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