เมื่อใดก็ตามที่คุณในฐานะนักพัฒนาได้รับงานตามโค้ดที่มีอยู่คุณต้องเผชิญกับความท้าทายมากมาย ความท้าทายอย่างหนึ่งซึ่งบ่อยกว่าไม่ใช่ความต้องการมากที่สุดคือการทำความเข้าใจรูปแบบข้อมูลของแอปพลิเคชัน
ปกติคุณจะต้องเผชิญกับตารางมุมมองคอลัมน์ค่าวิธีการจัดเก็บฟังก์ชันข้อ จำกัด และทริกเกอร์ที่ใช้เวลานานเพื่อให้เข้าใจตรงกัน และเมื่อเสร็จแล้วคุณจะเริ่มสังเกตเห็นหลายวิธีในการปรับปรุงและใช้ประโยชน์จากข้อมูลที่จัดเก็บไว้
หากคุณเป็นนักพัฒนาที่มีประสบการณ์มีโอกาสที่คุณจะสังเกตเห็นสิ่งต่างๆที่สามารถทำได้ดีขึ้นในช่วงแรกนั่นคือข้อบกพร่องในการออกแบบ
ในบทความนี้คุณจะได้เรียนรู้เกี่ยวกับแนวทางปฏิบัติที่ไม่ดีในการออกแบบฐานข้อมูลทั่วไปทำไมจึงไม่ดีและคุณจะหลีกเลี่ยงได้อย่างไร
ข้อมูลจะถูกจัดเก็บเพื่อใช้ในภายหลังและเป้าหมายคือการจัดเก็บและเรียกดูข้อมูลอย่างมีประสิทธิภาพสูงสุดเสมอ เพื่อให้บรรลุเป้าหมายนี้ผู้ออกแบบฐานข้อมูลจะต้องทราบล่วงหน้าว่าข้อมูลกำลังจะแสดงถึงอะไรจะได้มาอย่างไรและในอัตราเท่าใดปริมาณการดำเนินงานจะเป็นเท่าใด (กล่าวคือคาดว่าจะมีข้อมูลเท่าใด) และสุดท้าย , จะใช้อย่างไร.
ตัวอย่างเช่นระบบข้อมูลอุตสาหกรรมที่รวบรวมข้อมูลด้วยตนเองทุกวันจะไม่มีรูปแบบข้อมูลเหมือนกับระบบอุตสาหกรรมที่ข้อมูลถูกสร้างขึ้นตามเวลาจริง ทำไม? เนื่องจากมีความแตกต่างกันมากในการจัดการบันทึกไม่กี่ร้อยหรือหลายพันรายการต่อเดือนเมื่อเทียบกับ จัดการพวกเขาหลายล้านคน ในช่วงเวลาเดียวกัน ผู้ออกแบบจะต้องพิจารณาเป็นพิเศษเพื่อรักษาประสิทธิภาพและความสามารถในการใช้งานของฐานข้อมูลหากปริมาณข้อมูลมีขนาดใหญ่
แต่แน่นอนว่าปริมาณข้อมูลไม่ใช่ประเด็นเดียวที่ต้องพิจารณาเนื่องจากวัตถุประสงค์ของข้อมูลยังส่งผลต่อระดับของการทำให้เป็นมาตรฐานโครงสร้างข้อมูลขนาดบันทึกและการนำไปใช้งานทั่วไปของทั้งระบบ
ดังนั้นการทราบวัตถุประสงค์ของระบบข้อมูลอย่างละเอียดที่คุณจะสร้างจึงนำไปสู่การพิจารณาในการเลือกเอ็นจินฐานข้อมูลเอนทิตีในการออกแบบขนาดและรูปแบบของเรกคอร์ดและนโยบายการจัดการเอ็นจินฐานข้อมูล
การเพิกเฉยต่อเป้าหมายเหล่านี้จะนำไปสู่การออกแบบที่มีข้อบกพร่องในพื้นฐานแม้ว่าจะถูกต้องตามโครงสร้างและทางคณิตศาสตร์
การออกแบบฐานข้อมูลไม่ใช่งานกำหนด ผู้ออกแบบฐานข้อมูลสองคนอาจปฏิบัติตามกฎและหลักการนอร์มัลไลซ์ทั้งหมดสำหรับปัญหาที่กำหนดและในกรณีส่วนใหญ่พวกเขาจะสร้างเค้าโครงข้อมูลที่แตกต่างกัน สิ่งนี้มีอยู่ในลักษณะสร้างสรรค์ของวิศวกรรมซอฟต์แวร์ อย่างไรก็ตามมีเทคนิคการวิเคราะห์บางอย่างที่เหมาะสมในทุกกรณีและการปฏิบัติตามเป็นวิธีที่ดีที่สุดในการเข้าถึงฐานข้อมูลที่ทำงานได้ดีที่สุด
อย่างไรก็ตามเรามักเผชิญกับฐานข้อมูลที่ได้รับการออกแบบทันทีโดยไม่ปฏิบัติตามกฎพื้นฐานที่สุดของการทำให้เป็นมาตรฐาน เราต้องมีความชัดเจนในเรื่องนี้: อย่างน้อยทุกฐานข้อมูลควรได้รับการปรับให้เป็นรูปแบบปกติที่สามเนื่องจากเป็นรูปแบบที่จะแสดงถึงเอนทิตีของคุณได้ดีที่สุดและประสิทธิภาพของมันจะสมดุลกันดีที่สุดระหว่างการสืบค้นและการแทรก - การอัปเดต - การลบ .
หากคุณสะดุดกับตารางที่ไม่สอดคล้องกับ 3NF , 2NF หรือแม้แต่ 1NF ให้ลองออกแบบตารางเหล่านี้ใหม่ ความพยายามที่คุณลงทุนในการทำเช่นนั้นจะให้ผลตอบแทนในระยะสั้น
เกี่ยวข้องมากกับจุดก่อนหน้าเนื่องจากหนึ่งในไฟล์ เป้าหมายของการทำให้เป็นมาตรฐาน คือการลดความซ้ำซ้อนเป็นวิธีปฏิบัติที่ไม่ดีอีกอย่างหนึ่งซึ่งเกิดขึ้นบ่อยครั้ง
ช่องและตารางที่ซ้ำซ้อนเป็นฝันร้ายสำหรับนักพัฒนาเนื่องจากต้องใช้ตรรกะทางธุรกิจเพื่อให้ข้อมูลเดียวกันหลายเวอร์ชันเป็นปัจจุบันอยู่เสมอ นี่คือค่าใช้จ่ายที่สามารถหลีกเลี่ยงได้หากปฏิบัติตามกฎการทำให้เป็นมาตรฐานอย่างละเอียด แม้ว่าบางครั้งความซ้ำซ้อนอาจดูเหมือนจำเป็น แต่จะต้องใช้ในกรณีที่เฉพาะเจาะจงมากเท่านั้นและต้องมีการจัดทำเอกสารอย่างชัดเจนเพื่อนำมาพิจารณาในการพัฒนาในอนาคต
ผลเสียโดยทั่วไปของความซ้ำซ้อนคือการเพิ่มขนาดฐานข้อมูลโดยไม่จำเป็นข้อมูลมีแนวโน้มที่จะไม่สอดคล้องกันและประสิทธิภาพของฐานข้อมูลลดลง แต่ที่สำคัญกว่านั้นอาจทำให้ข้อมูลเสียหายได้
ความสมบูรณ์ของการอ้างอิงเป็นหนึ่งในเครื่องมือที่มีค่าที่สุดที่เอ็นจินฐานข้อมูลมีให้เพื่อรักษาคุณภาพของข้อมูลให้ดีที่สุด หากไม่มีการใช้ข้อ จำกัด หรือข้อ จำกัด น้อยมากตั้งแต่ขั้นตอนการออกแบบความสมบูรณ์ของข้อมูลจะต้องอาศัยตรรกะทางธุรกิจทั้งหมดทำให้เสี่ยงต่อความผิดพลาดของมนุษย์
เมื่อคุณใช้ไฟล์ เอ็นจิ้นฐานข้อมูล (DBE) คุณมีซอฟต์แวร์ที่มีประสิทธิภาพสำหรับงานจัดการข้อมูลของคุณซึ่งจะทำให้การพัฒนาซอฟต์แวร์ง่ายขึ้นและรับประกันว่าข้อมูลจะถูกต้องปลอดภัยและใช้งานได้เสมอ DBE ให้บริการเช่น:
การไม่รู้หรือเพิกเฉยต่อความสามารถเหล่านี้จะนำไปสู่การพัฒนาไปสู่เส้นทางที่ไม่แน่นอนอย่างยิ่งและแน่นอนว่าจะเกิดข้อบกพร่องและปัญหาในอนาคต
นี่เป็นประเด็นที่ถกเถียงกันอยู่เนื่องจากนักออกแบบฐานข้อมูลจำนวนมากพูดถึงการใช้ฟิลด์ที่สร้างขึ้นโดยอัตโนมัติของ ID จำนวนเต็มเป็นคีย์หลักแทนที่จะเป็นคอมโพสิตที่กำหนดโดยการรวมกันของสองฟิลด์ขึ้นไป ปัจจุบันนี้ถูกกำหนดให้เป็น 'แนวทางปฏิบัติที่ดีที่สุด' และโดยส่วนตัวแล้วฉันมักจะเห็นด้วยกับมัน
อย่างไรก็ตามนี่เป็นเพียงแบบแผนและแน่นอน DBE อนุญาตให้ใช้คำจำกัดความของ คอมโพสิตหลัก กุญแจซึ่งนักออกแบบหลายคนคิดว่าหลีกเลี่ยงไม่ได้ ดังนั้นเช่นเดียวกับความซ้ำซ้อนคีย์หลักแบบผสมจึงเป็นการตัดสินใจในการออกแบบ
อย่างไรก็ตามโปรดระวังว่าหากตารางของคุณที่มีคีย์หลักแบบผสมคาดว่าจะมีแถวหลายล้านแถวดัชนีที่ควบคุมคีย์คอมโพสิตสามารถเติบโตได้จนถึงจุดที่ประสิทธิภาพการทำงานของ CRUD ลดลงอย่างมาก ในกรณีนี้ควรใช้คีย์หลัก ID จำนวนเต็มอย่างง่ายซึ่งดัชนีจะกะทัดรัดเพียงพอและกำหนดข้อ จำกัด DBE ที่จำเป็นเพื่อรักษาความเป็นเอกลักษณ์
บางครั้งคุณจะมีตารางที่คุณต้องการค้นหาตามคอลัมน์จำนวนมาก เมื่อตารางใหญ่ขึ้นคุณจะสังเกตเห็นว่า SELECT ในคอลัมน์เหล่านี้ช้าลง หากตารางมีขนาดใหญ่พอคุณจะคิดอย่างมีเหตุผลในการสร้างดัชนีในแต่ละคอลัมน์ที่คุณใช้เพื่อเข้าถึงตารางนี้เท่านั้นเพื่อค้นหาเกือบจะในทันทีว่าประสิทธิภาพของ SELECT ดีขึ้น แต่ INSERTs, UPDATEs และ DELETEs ลดลง แน่นอนว่านี่เป็นเพราะความจริงที่ว่าดัชนีจะต้องถูกซิงโครไนซ์กับตารางซึ่งหมายถึงค่าใช้จ่ายจำนวนมากสำหรับ DBE นี่เป็นกรณีทั่วไปของการจัดทำดัชนีมากเกินไปซึ่งคุณสามารถแก้ไขได้หลายวิธี ตัวอย่างเช่นการมีดัชนีเดียวในคอลัมน์ทั้งหมดที่แตกต่างจากคีย์หลักที่คุณใช้ในการสืบค้นตารางการเรียงลำดับคอลัมน์เหล่านี้จากค่าที่ใช้มากที่สุดไปหาน้อยที่สุดอาจให้ประสิทธิภาพที่ดีกว่าในการดำเนินการ CRUD ทั้งหมดมากกว่าหนึ่งดัชนีต่อคอลัมน์
ในทางกลับกันการมีตารางที่ไม่มีดัชนีในคอลัมน์ที่ใช้ในการสืบค้นดังที่เราทุกคนทราบกันดีจะนำไปสู่ประสิทธิภาพที่ไม่ดีของ SELECT
นอกจากนี้ประสิทธิภาพของดัชนีบางครั้งขึ้นอยู่กับประเภทคอลัมน์ ดัชนีในคอลัมน์ INT แสดงประสิทธิภาพที่ดีที่สุด แต่ดัชนีใน VARCHAR, DATE หรือ DECIMAL (ถ้ามันสมเหตุสมผล) จะไม่มีประสิทธิภาพเท่า การพิจารณานี้อาจนำไปสู่การออกแบบตารางใหม่ที่จำเป็นต้องเข้าถึงด้วยประสิทธิภาพที่ดีที่สุด
ดังนั้นการจัดทำดัชนีจึงเป็นการตัดสินใจที่ละเอียดอ่อนเสมอเนื่องจากการจัดทำดัชนีมากเกินไปอาจส่งผลเสียน้อยเกินไปและเนื่องจากชนิดข้อมูลของคอลัมน์ที่จะจัดทำดัชนีมีอิทธิพลอย่างมากต่อผลลัพธ์สุดท้าย
นี่คือสิ่งที่โปรแกรมเมอร์มักจะต่อสู้เมื่อต้องเผชิญกับฐานข้อมูลที่มีอยู่: การทำความเข้าใจว่าข้อมูลใดถูกเก็บไว้ในชื่อของตารางและคอลัมน์เนื่องจากมักไม่มีวิธีอื่น
ชื่อตารางจะต้องอธิบายถึงเอนทิตีที่มีอยู่และชื่อคอลัมน์แต่ละชื่อต้องอธิบายถึงข้อมูลที่แสดง นี่เป็นเรื่องง่าย แต่จะเริ่มซับซ้อนเมื่อตารางต้องสัมพันธ์กัน ชื่อเริ่มยุ่งเหยิงและที่แย่กว่านั้นคือหากมีรูปแบบการตั้งชื่อที่สับสนกับบรรทัดฐานที่ไม่สมเหตุสมผล (เช่น 'ชื่อคอลัมน์ต้องมีอักขระไม่เกิน 8 ตัว') ผลสุดท้ายคือฐานข้อมูลไม่สามารถอ่านได้
ดังนั้นก หลักการตั้งชื่อ จำเป็นเสมอหากคาดว่าฐานข้อมูลจะคงอยู่และพัฒนาไปพร้อมกับแอพพลิเคชั่นที่รองรับและนี่คือแนวทางบางประการเพื่อสร้างความกระชับเรียบง่ายและอ่านได้:
มีแนวทางการตั้งชื่อฐานข้อมูลมากมายบนอินเทอร์เน็ตที่จะช่วยให้คุณเข้าใจสิ่งที่สำคัญมากขึ้นในการออกแบบฐานข้อมูล แต่ด้วยแนวทางพื้นฐานเหล่านี้อย่างน้อยคุณก็สามารถเข้าถึงฐานข้อมูลที่อ่านได้ สิ่งที่สำคัญที่นี่ไม่ใช่ขนาดหรือความซับซ้อนของแนวทางการตั้งชื่อของคุณ แต่เป็นความสม่ำเสมอในการปฏิบัติตาม!
การออกแบบฐานข้อมูลเป็นการผสมผสานระหว่างความรู้และประสบการณ์ อุตสาหกรรมซอฟต์แวร์มีการพัฒนาไปมากตั้งแต่ยุคแรก ๆ โชคดีที่มีความรู้เพียงพอที่จะช่วยได้ นักออกแบบฐานข้อมูล บรรลุผลลัพธ์ที่ดีที่สุด
มีการออกแบบฐานข้อมูลที่ดี แนวทาง ทั่วทั้งอินเทอร์เน็ตและ การปฏิบัติที่ไม่ดี และ สิ่งที่ควรหลีกเลี่ยง ในการออกแบบฐานข้อมูล เพียงแค่เลือกและติดมัน
และอย่าลืมว่าคุณได้เรียนรู้จากการทดลองความผิดพลาดและความสำเร็จเท่านั้นดังนั้นเริ่มเลย