ข้อ จำกัด ในฐานข้อมูลเชิงสัมพันธ์ - ทำไมไม่ลบอย่างสมบูรณ์?

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

เครื่องมือ ORM เช่น EntityContext, Linq2Data, NHibernate ยังจัดการกับข้อ จำกัด ด้วยตัวเองอย่างน้อยคุณก็รู้ว่าตารางใดที่ต้องการซึ่งกันและกัน การทำข้อ จำกัด ภายในเซิร์ฟเวอร์นั้นเกี่ยวกับการเปลี่ยนแปลง (บังคับ) เดียวกันสองครั้งหรือไม่?

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

เรื่องนี้ทำให้ฉันประหลาดใจและฉันไม่แน่ใจว่าจะจัดการกับมันอย่างไร

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

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

สองเหตุผลทั่วไปที่จะไม่ลบข้อ จำกัด ออกจากฐานข้อมูล :

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

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

แอปพลิเคชันสามารถมาและไปได้ แต่มีข้อมูลอยู่ตลอดไป ใน บริษัท ของฉัน DB มีอายุมากกว่า 30-40 ปีจะอยู่ต่อไปตราบเท่าที่ บริษัท มีอยู่ แอปพลิเคชั่นเปลี่ยนแปลงผู้พัฒนามาและไป มันจะดีกว่าถ้ามี integrity และโมเดลข้อมูลเชิงตรรกะที่ดี ด้วยวิธีนี้ใครบางคนสามารถดูข้อมูลและรับความเข้าใจที่มีความหมายได้โดยไม่ต้องผ่านฐานข้อมูลที่ซับซ้อน นอกจากนี้ยังช่วยในการรายงานอย่างมีนัยสำคัญ แอปพลิเคชันสามารถและจะมีข้อบกพร่องและข้อ จำกัด ของฐานข้อมูลเป็นตัวป้องกัน ตำแหน่งเริ่มต้นของฉันคือมีข้อ จำกัด มาก (FK และตรวจสอบ) เท่าที่จะทำได้
เหตุผลเดียวที่จะไม่มีข้อ จำกัด คือถ้ารูปแบบการออกแบบของคุณไม่อนุญาตเช่นปัญหาตารางต่อลำดับชั้นหรือปัญหาประสิทธิภาพ

สิ่งที่รบกวนฉันคือข้อ จำกัด ทั้งหมดที่กำหนดค่าไว้ภายใน SQLserver ด้วย "not cascade"

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

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

โดยทั่วไปแล้วฐานข้อมูลจะถูกดำเนินการโดยหลาย ๆ แอปพลิเคชั่น = เว็บไซต์หรือแอพพลิเคชั่นบนเดสก์ท็อปแอปพลิเคชั่นรายงานเว็บเซอร์วิสหน้าต่างการสืบค้นกระบวนการ ETL เป็นต้นหากคุณไม่บังคับใช้ข้อ จำกัด ในระดับฐานข้อมูล ของข้อมูลที่เป็นหนึ่งในแอปพลิเคชันเหล่านั้นอาจไม่ปฏิบัติตามกฎทั้งหมด ประการที่สองคุณต้องเขียนโค้ดข้อห้ามเหล่านั้นหลายครั้งแล้วเขียนใหม่หากคุณตัดสินใจใช้แอปพลิเคชันอื่นในภายหลัง ประการที่สามคุณไม่สามารถควบคุมล่วงหน้าได้ว่าจะต้องดำเนินการบำรุงรักษาข้อมูลบางประเภทที่จะไม่เกิดขึ้นผ่านแอปพลิเคชันหรือไม่ (แก้ไขข้อมูลจากการนำเข้าข้อมูลลูกค้าที่ไม่ดีเช่นหรือเปลี่ยนแปลง 10,000,000 ระเบียนทั้งหมดจากไคลเอนต์หนึ่งราย ไปยังลูกค้ารายอื่นเมื่อ บริษัท คู่แข่งซื้อโดย) นักพัฒนาแอปพลิเคชันโดยทั่วไปจะไม่ '

ผมอ่านบางครั้งหนึ่งที่กล่าวว่าโดยทั่วไป: ข้อมูลที่สำคัญของแอพลิเคชันของคุณ หากคุณจะเข้าถึงข้อมูลผ่าน UI ของคุณเท่านั้น (และฉันหมายถึงอย่างที่ไม่เคยมีมาก่อนและตลอดไปสำหรับนิรันดร์ ... หรือตลอดชีวิตของแอปพลิเคชันของคุณ) คุณไม่จำเป็นต้องมีข้อ จำกัด ของฐานข้อมูล แต่มีโอกาสที่สิ่งอื่นที่ไม่ใช่แอพจะต้องสัมผัสกับข้อมูลเช่นบริการเว็บ, API สาธารณะ, งานคราด / งาน SQL / cron / สคริปต์อัตโนมัติจากนั้นคุณจะช่วยตัวเองปัญหาที่อาจเกิดขึ้นลง ถนนโดยการรักษาข้อ จำกัด DB

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

คุณรู้หรือไม่ว่า ORM หมายถึงอะไร? การทำแผนที่วัตถุสัมพันธ์ การอ้างอิง Wikipedia "เทคนิคการแปลงข้อมูลระหว่างระบบประเภทที่เข้ากันไม่ได้ " ใช่โมเดลเชิงสัมพันธ์และโมเดลวัตถุไม่สอดคล้องกัน ORMs ทำการแปลงที่ค่อนข้างดีโดยเคารพกฎของระบบทั้งสองชนิด RDBMS ถูกจัดระเบียบในลักษณะเช่นนี้เพื่อให้คุณได้รับข้อมูลที่สมบูรณ์โดยใช้ข้อ จำกัด โดยทั่วไปความสมบูรณ์เป็นสิ่งที่ดีมากดังนั้น ORM จึงมักใช้เมื่อสร้างแบบจำลองข้อมูลสำหรับจัดเก็บข้อมูลวัตถุ ORM ของคุณอาจมีเหตุผลที่ดีที่จะใช้ข้อ จำกัด "ที่ไม่ใช่ทั้งหมด" และหากสิ่งนี้บังคับให้คุณทำการสืบค้นที่ซับซ้อนแทนเพียงแค่สร้าง / อัปเดต / วางวัตถุบางอย่างแล้วมีบางอย่างผิดปกติกับการตั้งค่า ORM ของคุณ

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

นั่นคือสิ่งที่ eBay ทำและพวกเขาอาจมีหนึ่งในฐานข้อมูลที่ใหญ่ที่สุดในโลก:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

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

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

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

ครั้งแรก - คำตอบของฉัน: ไม่คุณไม่ควรพึ่งพาแอปพลิเคชันเพียงอย่างเดียวเพื่อดูแลข้อมูลของคุณ

สิ่งนี้ชี้ให้เห็นถึงการถกเถียงที่ใหญ่กว่า: ORMs สนับสนุนวัฒนธรรมการดูถูกเหยียดหยามสำหรับการโต้ตอบ DB โดยตรงซึ่งมักจะเป็นค่าใช้จ่ายในการทำให้เป็นมาตรฐาน / การอ้างอิงที่สมบูรณ์ ตารางถูกแมปด้วยการบังคับให้ลำดับชั้นวัตถุโดยค่าใช้จ่ายของการออกแบบโดยนัยในรูปแบบเชิงสัมพันธ์ การแยก decoupling ที่ OOP ชื่นชอบนั้นมีเนื้อหาที่นี่เนื่องจากแอปพลิเคชันทำให้รู้สึกถึงการออกแบบในโครงสร้างข้อมูล ในขณะที่ ORM ได้แสดงให้เห็นถึงประโยชน์ที่ดีเยี่ยมดูเหมือนว่าจะเป็นไปตามการละเมิดหรือความไม่ไว้วางใจของ SQL

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

ฉันเห็นด้วยกับ @Jacek Prucia - ฉันคิดว่า ORM เป็นการจับคู่ที่ไม่ดีสำหรับ RDBMS ฉันจะเลือก DBAL บน RDBMS เป็นการส่วนตัวหรือไป OODB กับ ORM

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

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

เมื่อพัฒนาให้ใช้งานง่าย ข้อ จำกัด ให้คุณทำอย่างนั้น (ที่กล่าวว่าเมื่อข้อ จำกัด เกิดข้อผิดพลาดอย่าคายข้อผิดพลาดเดิมกลับมาที่ผู้ใช้ทำให้เกิดข้อผิดพลาดที่เข้าใจได้)

(สำหรับปัญหาเกี่ยวกับน้ำตก: นั่นเป็นสิ่งที่ดีฉันต้องการที่จะโยนข้อผิดพลาดที่บันทึกอื่น ๆ บางอย่างต้องถูกลบออกก่อนแทนที่จะพึ่งพาน้ำตกเพื่อให้ได้ทุกอย่างถูกต้อง Cascades นั้นดีในทางทฤษฎี ดังนั้นในทางปฏิบัติ)

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

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

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

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

กรณีหนึ่งที่ใช้งานได้คือแอพพลิเคชั่นระดับองค์กรขนาดใหญ่อย่าง PeopleSoft และ SAP ซึ่งแอปพลิเคชันนั้นทำทุกอย่างได้จริงและมีวิธีกำหนดไว้อย่างละเอียดเพื่อขยาย มีความเป็นไปได้อื่น ๆ ที่หายากมาก

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