ในการพัฒนาแบบเปรียวฉันควรลองความคงอยู่ในไฟล์แฟล็ตก่อนฐานข้อมูลหรือไม่?

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

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

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

อย่างไรก็ตามตัวอย่างที่นำมาใช้จริงขึ้นอยู่กับสมมติฐานที่ผิดพลาดอย่างสมบูรณ์ที่จะเริ่มต้นด้วย:

จะง่ายกว่าหรือน้อยกว่าในการใช้ฐานข้อมูลไฟล์แบบแฟลตกว่าใช้ RDBMS - มักเป็นเท็จอย่างสมบูรณ์

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

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

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

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

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

สิ่งหนึ่งที่คุณสามารถทำได้เพื่อลดความซับซ้อนของความซับซ้อนเริ่มต้นโดยใช้สิ่งที่ต้องการเช่นSQLite (ไลบรารีที่ให้ฐานข้อมูล SQL แบบไม่มีเซิร์ฟเวอร์ที่เก็บไว้ในไฟล์) มันมีระบบประเภทที่ยืดหยุ่นดังนั้นคุณไม่ต้องผูกมัดกับ schema อย่างจริงจังไม่มีเซิร์ฟเวอร์ที่จะกำหนดค่า / เชื่อมต่อกับ & สร้างฐานข้อมูลของคุณใหม่นั้นง่ายพอ ๆ กับการลบไฟล์ นอกจากนี้ยังช่วยให้คุณสามารถรวมภาพ DB พร้อมกับรหัสในการควบคุมเวอร์ชันหากจำเป็น

มันเป็นตัวอย่างที่ใช้ในการสาธิตแนวคิดแทนที่จะเป็นแนวคิดในตัวมันเอง

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

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

แต่การเปลี่ยนจาก MySql บน Linux เป็น SQL Server บน Windows อาจไม่ง่ายเหมือนการเปลี่ยนจากไฟล์แบบแฟลตไปที่ SQL Server บน Windows นั่นคือจุดที่แท้จริง ดังนั้นในขณะที่มีข้อสงสัยเกี่ยวกับวิธีแก้ไขปัญหาขั้นสุดท้ายให้เลือกตัวเลือกที่ง่ายที่สุดที่เป็นไปได้สำหรับการเปลี่ยนแปลง เมื่อทำการตัดสินใจแล้ว

สิ่งที่คุณกำลัง persisting?

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

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

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

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

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

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

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

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

มุมมองเกี่ยวกับกลยุทธ์การชะลอการเก็บข้อมูลได้รับการสนับสนุนในการนำเสนอนี้โดย Robert C. Martin (หนึ่งในผู้แต่งรายการ agile)

มันเป็นการนำเสนอที่ดีมากฉันขอแนะนำให้คุณดู

แต่ฉันไม่เห็นด้วยกับมัน! อย่างน้อยถึงระดับ

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

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

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

ต้องใช้วิจารณญาณและประสบการณ์ที่ดีในการดูว่าคำถามใดต้องตอบก่อนเมื่อเริ่มโครงการใหม่

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

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

ไฟล์แบนไม่ง่าย!

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

มีฐานข้อมูลเหตุผลอยู่และหนึ่งในนั้นคือการทำให้สิ่งต่าง ๆ ง่ายขึ้นสำหรับนักพัฒนา

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

รายการข้อมูลที่ถูกลืมโครงสร้างข้อมูลที่ไม่ตรงกันและฝันร้ายอื่น ๆ ทั้งหมดสามารถหลีกเลี่ยงได้โดยการสร้างแบบจำลองข้อมูลขึ้นด้านหน้า

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

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

คุณควรพยายามคงอยู่ในไฟล์แฟล็ตก่อนฐานข้อมูลหรือไม่?

ใช่คุณควรลอง โดยเฉพาะถ้าคุณไม่เคยลองมาก่อน ไม่ว่ามันจะเกิดขึ้นได้อย่างไรคุณจะได้เรียนรู้บางสิ่ง