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

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

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

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

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

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

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

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

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

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

แนวทางปฏิบัติที่ไม่ดีฉบับที่ 2: การทำให้ปกติไม่ดี

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

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

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

แนวทางปฏิบัติที่ไม่ดีข้อที่ 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 ถ้าจะเรียกคอลัมน์ว่า“ Index” ซึ่งเป็นคำสงวนของ SQL ให้ลองใช้คอลัมน์อื่นเช่น“ IndexNumber”
• หากยึดตามกฎคีย์หลักอย่างง่าย (สร้างจำนวนเต็มเดียวอัตโนมัติ) ให้ตั้งชื่อว่า 'Id' ในทุกตาราง
• หากเข้าร่วมกับตารางอื่นให้กำหนด Foreign Key ที่จำเป็นเป็นจำนวนเต็มชื่อ“ Id” ตามด้วยชื่อของตารางที่เข้าร่วม (เช่น IdItem)
• หากมีข้อ จำกัด ในการตั้งชื่อให้ใช้คำนำหน้าที่อธิบายข้อ จำกัด (เช่น“ PK” หรือ“ FK”) ตามด้วยชื่อของตารางหรือตารางที่เกี่ยวข้อง แน่นอนว่าการใช้เครื่องหมายขีดล่าง (“ _”) เท่าที่จำเป็นจะช่วยให้อ่านสิ่งต่างๆได้ง่ายขึ้น
• ในการตั้งชื่อดัชนีให้ใช้คำนำหน้า“ IDX” ตามด้วยชื่อตารางและคอลัมน์หรือคอลัมน์ของดัชนี นอกจากนี้ให้ใช้“ UNIQUE” เป็นคำนำหน้าหรือคำต่อท้ายหากดัชนีไม่ซ้ำกันและขีดเส้นใต้หากจำเป็น

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

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

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

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

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