แนวทางปฏิบัติที่ไม่ดีในการออกแบบฐานข้อมูล: คุณทำผิดพลาดหรือไม่?

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

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

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

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

แนวปฏิบัติที่แย่ข้อที่ 1: การเพิกเฉยต่อจุดประสงค์ของข้อมูล

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

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

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

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

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

แนวปฏิบัติที่แย่ข้อที่ 2: การทำให้เป็นมาตรฐานที่ไม่ดี

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

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

หากคุณสะดุดกับตารางที่ไม่สอดคล้องกับ 3NF, 2NF หรือแม้แต่ 1NF ให้พิจารณาออกแบบตารางเหล่านี้ใหม่ ความพยายามที่คุณลงทุนในการทำเช่นนี้จะได้ผลในระยะสั้น

Bad Practice No. 3: ความซ้ำซ้อน

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

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

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

แนวทางปฏิบัติที่แย่ข้อที่ 4: ความสมบูรณ์ของการอ้างอิงที่ไม่ถูกต้อง (ข้อจำกัด)

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

แนวทางปฏิบัติที่แย่ข้อที่ 5: ไม่ใช้ประโยชน์จากคุณลักษณะของ DB Engine

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

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

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

แนวปฏิบัติที่ไม่เหมาะสมหมายเลข 6: คีย์หลักแบบผสม

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

อย่างไรก็ตาม นี่เป็นเพียงข้อตกลง และแน่นอน DBE อนุญาตให้นิยามคีย์หลักแบบผสม ซึ่งนักออกแบบหลายคนคิดว่าหลีกเลี่ยงไม่ได้ ดังนั้น เช่นเดียวกับความซ้ำซ้อน คีย์หลักแบบผสมจึงเป็นการตัดสินใจในการออกแบบ

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

แนวทางปฏิบัติที่แย่ข้อ 7: การจัดทำดัชนีไม่ดี

บางครั้ง คุณจะมีตารางที่คุณต้องการสอบถามตามคอลัมน์ต่างๆ เมื่อตารางเติบโตขึ้น คุณจะสังเกตเห็นว่า SELECT ในคอลัมน์เหล่านี้ช้าลง หากตารางมีขนาดใหญ่พอ คุณจะต้องคิดตามหลักเหตุผลว่าควรสร้างดัชนีในแต่ละคอลัมน์ที่คุณใช้เพื่อเข้าถึงตารางนี้ แต่จะพบว่าเกือบจะในทันทีว่าประสิทธิภาพของ SELECT ดีขึ้น แต่ INSERTs, UPDATEs และ DELETEs จะลดลง แน่นอนว่าสิ่งนี้เกิดจากการที่ดัชนีต้องซิงโครไนซ์กับตาราง ซึ่งหมายถึงค่าใช้จ่ายมหาศาลสำหรับ DBE นี่เป็นกรณีทั่วไปของการจัดทำดัชนีมากเกินไป ซึ่งคุณสามารถแก้ไขได้หลายวิธี ตัวอย่างเช่น การมีดัชนีเดียวในทุกคอลัมน์ที่แตกต่างจากคีย์หลักที่คุณใช้ในการสืบค้นตาราง การเรียงลำดับคอลัมน์เหล่านี้จากคอลัมน์ที่ใช้มากที่สุดไปน้อยที่สุดอาจให้ประสิทธิภาพที่ดีกว่าในการดำเนินการ CRUD ทั้งหมดมากกว่าหนึ่งดัชนีต่อคอลัมน์

ในทางกลับกัน การมีตารางที่ไม่มีดัชนีในคอลัมน์ที่ใช้ในการสืบค้น อย่างที่เราทราบกันดีจะทำให้ SELECT มีประสิทธิภาพต่ำ

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

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

แนวปฏิบัติแย่ๆ ที่ 8: แบบแผนการตั้งชื่อที่ไม่ดี

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

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

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

• ไม่มีข้อจำกัดเกี่ยวกับขนาดชื่อตารางหรือคอลัมน์ การมีชื่อที่สื่อความหมายได้ดีกว่าตัวย่อที่ไม่มีใครจำหรือเข้าใจ
• ชื่อที่เท่ากันมีความหมายเหมือนกัน หลีกเลี่ยงการมีฟิลด์ที่มีชื่อเหมือนกัน แต่มีประเภทหรือความหมายต่างกัน สิ่งนี้จะทำให้เกิดความสับสนไม่ช้าก็เร็ว
• ถ้าไม่จำเป็นอย่าซ้ำซาก ตัวอย่างเช่น ในตาราง "สินค้า" ไม่จำเป็นต้องมีคอลัมน์เช่น "ItemName" "PriceOfItem" หรือชื่อที่คล้ายกัน “ชื่อ” และ “ราคา” ก็เพียงพอแล้ว
• ระวังคำสงวน DBE หากคอลัมน์จะเรียกว่า "ดัชนี" ซึ่งเป็นคำสงวนของ SQL ลองใช้คอลัมน์อื่นเช่น "IndexNumber"
• หากยึดตามกฎคีย์หลักอย่างง่าย (สร้างจำนวนเต็มเดียวโดยอัตโนมัติ) ให้ตั้งชื่อว่า "Id" ในทุกตาราง
• หากเข้าร่วมตารางอื่น ให้กำหนด foreign key ที่จำเป็นเป็นจำนวนเต็ม ชื่อ “Id” ตามด้วยชื่อของตารางที่เข้าร่วม (เช่น IdItem)
• หากมีข้อจำกัดในการตั้งชื่อ ให้ใช้คำนำหน้าที่อธิบายข้อจำกัด (เช่น “PK” หรือ “FK”) ตามด้วยชื่อของตารางหรือตารางที่เกี่ยวข้อง แน่นอนว่าการใช้ขีดล่าง (“_”) เพียงเล็กน้อยจะช่วยให้อ่านสิ่งต่างๆ ได้ง่ายขึ้น
• หากต้องการตั้งชื่อดัชนี ให้ใช้คำนำหน้า "IDX" ตามด้วยชื่อตารางและคอลัมน์หรือคอลัมน์ของดัชนี นอกจากนี้ ให้ใช้ “UNIQUE” เป็นคำนำหน้าหรือส่วนต่อท้ายหากดัชนีไม่ซ้ำกัน และขีดเส้นใต้ในกรณีที่จำเป็น

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

ข้อสังเกตสุดท้ายบางประการ

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

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

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