เกิดอะไรขึ้นกับข้อ จำกัด ของฐานข้อมูล

เมื่อฉันตรวจสอบโมเดลฐานข้อมูลสำหรับ RDBMS ฉันมักจะประหลาดใจที่พบข้อ จำกัด เพียงเล็กน้อยหรือไม่มีเลย (นอกเหนือจาก PK / FK) ตัวอย่างเช่นเปอร์เซ็นต์มักถูกเก็บไว้ในคอลัมน์ประเภทint(ในขณะที่tinyintจะเหมาะสมกว่า) และไม่มีCHECKข้อ จำกัด ในการ จำกัด ค่าให้อยู่ในช่วง 0..100 ในทำนองเดียวกันกับ SE.SE คำตอบที่แนะนำข้อ จำกัด การตรวจสอบมักจะได้รับความคิดเห็นที่แนะนำว่าฐานข้อมูลเป็นสถานที่ที่ไม่ถูกต้องสำหรับข้อ จำกัด

เมื่อฉันถามเกี่ยวกับการตัดสินใจที่จะไม่บังคับใช้ข้อ จำกัด สมาชิกในทีมตอบว่า:

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

• หรือว่าพวกเขาบังคับใช้ข้อ จำกัด ดังกล่าวในระดับแอปพลิเคชันและการทำซ้ำกฎเหล่านั้นในฐานข้อมูลไม่ใช่ความคิดที่ดีละเมิด SSOT

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

เมื่อถามทีมถึงทางเลือกที่จะไม่ใช้ FK พวกเขาบอกว่า:

• มันเป็น PITA เช่นเมื่อต้องลบองค์ประกอบที่อ้างอิงในตารางอื่น ๆ

• หิน NoSQL และไม่มีกุญแจต่างประเทศอยู่ที่นั่น ดังนั้นเราไม่ต้องการพวกมันใน RDBMS

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

เมื่อฉันดูที่แอปพลิเคชันตัวเองฉันสังเกตเห็นรูปแบบสองรูปแบบ:

• แอปพลิเคชั่นจะทำการรักษาข้อมูลให้ถูกต้องและตรวจสอบก่อนที่จะส่งไปยังฐานข้อมูล ตัวอย่างเช่นไม่มีวิธีเก็บค่า102เป็นเปอร์เซ็นต์ผ่านแอปพลิเคชัน

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

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

และคำถามของฉันมาที่นี่:

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

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

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

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

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

เมื่อนักพัฒนาจากภูมิหลังที่แตกต่างเหล่านี้มาพบคุณจะได้รับการปะทะกันทางวัฒนธรรม

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

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

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

จากการศึกษาทฤษฎีบท CAP คุณจะเห็นว่าไม่มีทางเลือกมากนัก แต่เลือกที่จะสูญเสียความพร้อมใช้งานหรือความสอดคล้องเนื่องจากคุณไม่สามารถไว้วางใจในเครือข่ายได้ 100%

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

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

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

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

- แก้ไข: -

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

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

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

ก่อนอื่นให้ชัดเจนว่าฉันกำลังพูดถึงที่นี่เกี่ยวกับ RDBM ไม่ใช่ฐานข้อมูลที่ไม่ใช่ SQL

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

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

• ในกรณีของผู้เริ่มต้นหรือโปรแกรมเมอร์งานอดิเรก , al ack ของทักษะการสร้างแบบจำลอง
• การใช้ ORM อย่างกว้างขวางหรือเกือบพิเศษโดยไม่ต้องมีการติดต่อกับโลกแห่งฐานข้อมูล
• การขาด DBA หรือผู้เชี่ยวชาญด้านการสร้างแบบจำลองข้อมูลอื่น ๆในทีมหรือโครงการขนาดเล็ก
• ขาดการมีส่วนร่วมของ DBA หรือผู้เชี่ยวชาญด้านการสร้างแบบจำลองข้อมูลในระยะแรกของการพัฒนา
• ตัดสินใจในการออกแบบโดยเจตนาโดยเป็นส่วนหนึ่งของชุมชนนักพัฒนาที่จะพิจารณาว่าแม้ข้อ จำกัด การตรวจสอบที่บังคับว่าคอลัมน์บางอย่างอาจมีเพียง1,2 or 3เป็นค่าหรือว่า "อายุ" คอลัมน์จะต้อง>= 0มีการ"มีตรรกะทางธุรกิจในฐานข้อมูล" แม้แต่ประโยคเริ่มต้นก็ยังถือว่าเป็นตรรกะทางธุรกิจที่ไม่ได้อยู่ในฐานข้อมูลอย่างที่คุณเห็นในคำถามและคำตอบล่าสุดในเว็บไซต์นี้ นักพัฒนานี้ที่พิจารณาอย่างชัดเจนว่าจะใช้ข้อ จำกัด น้อยที่สุดเท่าที่จะเป็นไปได้และจะทำทุกอย่างในโค้ดแม้แต่ความสมบูรณ์ของการอ้างอิงและ / หรือการรวมกัน ฉันคิดว่านี่เป็นตำแหน่งที่สุดยอด
• การใช้ RDBMs เป็นที่เก็บคีย์ - ค่าอาจใช้เพื่อเลียนแบบพฤติกรรมที่ไม่ใช่ SQL ของเพราะการแสดงผลที่ง่ายพอที่จะทำให้พอใจโดยใช้ตาราง RDBMS เป็นตัวแยกที่เก็บคีย์ - ค่า
• สมมติว่าฐานข้อมูลจะถูกเขียนโดย "แอพ" เสมอและไม่มีใครจะต้องทำการโหลดข้อมูลจำนวนมากหรือแก้ไขหรือแทรกแถวผ่านไคลเอนต์ SQL (ในหลายกรณีเพื่อแก้ไขข้อมูลที่ไม่ถูกต้องที่แอปแทรก) ในกรณีที่ดีที่สุด escenario จะมีแอปอื่น (นอกเหนือจาก "แอพ") ออกคำสั่ง DML ไปยังฐานข้อมูล: ไคลเอนต์ SQL
• ไม่ทราบว่าข้อมูลเป็นของเจ้าของธุรกิจไม่ใช่สำหรับแอป

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

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

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

1. องค์กรมีผู้พัฒนาทั้งแอพและฐานข้อมูลพร้อมกับ DBA แต่นักพัฒนาส่วนใหญ่ไม่ทำงานในสภาพแวดล้อมประเภทนี้ พวกเขาทำเท่าที่จะทำได้ในรหัส นอกจากนี้บางส่วนในด้านฐานข้อมูลไม่เกี่ยวข้องกับกฎเกณฑ์ทางธุรกิจ พวกเขาส่วนใหญ่อยู่ที่นั่นเพื่อให้สิ่งต่าง ๆ ทำงานต่อไป พวกเขาจะไม่ผลักดันข้อ จำกัด ในฐานข้อมูล การจัดการกับแอพรุ่นเก่าการผสานรวมการโอนย้ายการควบรวมกิจการการได้มาซึ่งข้อ จำกัด ของ db อาจเป็นทางออกที่ดีที่สุด
2. การโหลดมากเกินไป db สามารถสร้างคอขวดที่ไม่สามารถแก้ไขได้ง่ายโดยการขว้างเครื่องมากขึ้นที่ปัญหา มีบางสถานการณ์ที่ภาษา db ไม่สามารถจัดการกับปัญหาการเขียนโปรแกรมโดยไม่ได้รับผลกระทบอย่างมากดังนั้นคุณจึงไม่สามารถวางแผนใช้ข้อ จำกัด สำหรับทุกสิ่งได้ Stackoverflow มีเซิร์ฟเวอร์ฐานข้อมูลเดียวเนื่องจากการขว้าง 2 ที่ปัญหาเป็นสิ่งที่ท้าทาย
3. การทดสอบอัตโนมัติ - พวกเขากำลังไปถึงจุดนั้น แต่นักพัฒนาฐานข้อมูลจำนวนมากก็มาช้าพร้อมกับกรอบ IDE / การทดสอบ
4. การปรับใช้ - สิ่งฐานข้อมูลเพิ่มเติมทำให้มีความซับซ้อนมากขึ้น จะเกิดอะไรขึ้นหากไม่อนุญาตให้อัปเดตฐานข้อมูลของลูกค้าเนื่องจากมีข้อมูลที่ละเมิดข้อ จำกัด จบเกมจนกว่าคุณจะมีวิธีแก้ไขปัญหานี้ ในแอพของคุณคุณอาจตัดสินใจให้ผู้ใช้จัดการสิ่งนี้ตามต้องการหรือสั่งให้ผู้ดูแลระบบบางคนทำเป็นแบทช์
5. เฉพาะแอพ / api / service เท่านั้นที่จะเขียนข้อมูลไปยังฐานข้อมูลดังนั้นทำไมต้องกังวล? นี่เป็นการระงับเวลาส่วนใหญ่ซึ่งเป็นสาเหตุที่ไม่เป็นเรื่องปกติ
6. การจัดการข้อผิดพลาดของฐานข้อมูลนั้นยากพอโดยไม่มีการละเมิดข้อ จำกัด หลายร้อยข้อเพื่อยืนยันว่าหากทุกอย่างหลุดออกมาจากการทำงาน

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

นี่เป็นปัญหาที่ฉันได้ต่อสู้กับอาชีพทั้งหมดของฉัน (เกือบ 40 ปี) และเมื่อฉันเขียน DBMS ของฉัน คำอธิบายของจุดสิ้นสุดของฉันอยู่ที่นี่: http://unibase.zenucom.com ดังนั้นนี่คือความคิดของฉัน

1. โดยทั่วไปการพูดข้อ จำกัด ส่วนใหญ่ได้รับการจัดการที่ดีขึ้นในแอปพลิเคชันเพื่อให้ส่วนต่าง ๆ ของแอปพลิเคชันสามารถบังคับใช้ข้อ จำกัด ที่แตกต่างกัน เช่นรหัสรัฐอาจใช้ไม่ได้ในทุกเขตอำนาจศาล
2. ในฐานะที่เป็นกันระวังของ% มาร์กอัปคือ> 100% หรือคุณพัง :)
3. ข้อ จำกัด จะอธิบายได้ดีที่สุดในทางลบ คือสิ่งที่พวกเขาไม่สามารถไม่ใช่สิ่งที่ควรจะเป็น มันเป็นรายการที่ง่ายกว่าเสมอ
4. ปุ่มต่างประเทศดีอยู่เสมอและควรใช้ fullstop FK เป็นหนึ่งในโครงสร้างความหมายไม่กี่แห่งใน RDBMS และมีประโยชน์มาก ความยากที่สุดที่ใหญ่ที่สุดคือการตัดสินใจว่าจะให้ค่าห้อยถ้าลบ FK หรือใช้แถวขึ้นอยู่กับเหตุผลที่จะไม่ลบระเบียน FK
5. ข้อ จำกัด ในโลกแห่งความเป็นจริงมักจะซับซ้อนกว่าข้อ จำกัด ด้านค่าเดียว
6. ข้อ จำกัด บางประการแม้แต่ในระดับแอปพลิเคชันก็สามารถทำงานกับการปฏิบัติงานที่ดีได้ เช่นการตรวจสอบวันที่ก้าวร้าวซ่อนข้อผิดพลาดในวันที่ดีที่เห็นได้ชัด คุณต้องมีข้อผิดพลาดของโอเปอเรเตอร์เพื่อรับข้อผิดพลาดในวันที่ที่เหมาะสม

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

บ่อยครั้งที่ผู้คนใช้ซอฟต์แวร์ (เช่น Entity Framework) เพื่อสร้างตารางและคอลัมน์โดยอัตโนมัติ แนวคิดก็คือพวกเขาไม่ต้องการทักษะ SQL เพิ่มความสามารถของสมอง

ความคาดหวังว่าซอฟต์แวร์จะ "ทำงานให้สำเร็จ" มักจะไม่สมจริงและไม่ได้สร้างข้อ จำกัด ที่มนุษย์ต้องการ

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