ซ้อนกันดูการออกแบบฐานข้อมูลที่ดี?

ฉันได้อ่านนานมาแล้ว หนังสือระบุว่าเราไม่ควรอนุญาตให้มีมุมมองแบบซ้อนใน SQL Server ฉันไม่แน่ใจว่าทำไมเราไม่สามารถทำเช่นนั้นหรือฉันอาจจำคำสั่งที่ไม่ถูกต้อง

นักเรียน

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

ครู

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

โรงเรียน

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

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

หากไม่เป็นเช่นนั้นฉันต้องการรู้ว่ามัน จำกัด อยู่ที่ SQL Server หรือสำหรับการออกแบบฐานข้อมูลโดยทั่วไป

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

ไม่คำนึงถึงแพลตฟอร์มจะใช้คำพูดต่อไปนี้

(-) มุมมองซ้อน:

• ยากที่จะเข้าใจและแก้ปัญหา

  เช่นคอลัมน์ตารางใดที่คอลัมน์มุมมองนี้อ้างถึง Lemme ขุดผ่านนิยามการดู 4 ระดับ ...

• ทำให้การเพิ่มประสิทธิภาพการสืบค้นทำได้ยากขึ้นด้วยแผนการสืบค้นที่มีประสิทธิภาพที่สุด

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

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

(+) ในมุมมองที่ซ้อนกันให้คุณ:

• รวมศูนย์และใช้ซ้ำการรวมหรือกฎธุรกิจ
• สรุปโครงสร้างพื้นฐานของคุณ (เช่นจากนักพัฒนาฐานข้อมูลอื่น)

ฉันพบว่าพวกเขาไม่ค่อยจำเป็น

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

• Keep: การเก็บมุมมองซ้อนไว้ทำให้คุณได้รับข้อดีและข้อเสียที่ระบุไว้ด้านบน

• ลบ: หากต้องการลบมุมมองแบบซ้อน:

  1. คุณต้องแทนที่การดูทั้งหมดด้วยการสืบค้นพื้นฐาน

  2. คุณต้องจำไว้ว่าต้องอัปเดตข้อความค้นหาที่เกี่ยวข้องทั้งหมดหากคำจำกัดความของคุณเกี่ยวกับการเปลี่ยนแปลงของนักเรียน / ครู / โรงเรียนที่มีสิทธิ์ซึ่งตรงข้ามกับการอัพเดตคำจำกัดความมุมมองที่เกี่ยวข้อง

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

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

SQL เวอร์ชันที่ใหม่กว่า (2005+) ดูดีขึ้นเมื่อปรับการใช้มุมมองให้เหมาะสมที่สุด มุมมองที่ดีที่สุดสำหรับการรวมกฎธุรกิจ EG: ฉันทำงานที่ไหนเรามีฐานข้อมูลผลิตภัณฑ์โทรคมนาคม แต่ละผลิตภัณฑ์ถูกกำหนดให้กับ rateplan และ rateplan นั้นสามารถสลับออกได้และอัตราของ rateplan สามารถเปิดใช้งาน / ปิดการใช้งานได้เนื่องจากอัตราจะเพิ่มขึ้นหรือปรับเปลี่ยน

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

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

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

สิ่งที่ดีเกี่ยวกับเรื่องนี้คือมุมมองที่ช่วยให้คุณลดการค้นหารายงานการเรียกเก็บเงินและอื่น ๆ คุณสามารถมีมุมมองบัญชีลูกค้าจากนั้นเป็นมุมมองระดับที่ 2 ของลูกค้าที่ใช้งานอยู่ ทีมที่มีมุมมองที่อยู่ลูกค้า ทีมที่มีมุมมองของผลิตภัณฑ์ (เข้าร่วมกับสิ่งที่ลูกค้ามี) ทีมที่จะดูแผนอัตราสินค้า ทีมที่มีมุมมองคุณลักษณะของผลิตภัณฑ์ ดู, ดู, ดู, แต่ละการทดลอง -n-errored เพื่อความสมบูรณ์ ข้อความค้นหาปลายทางของคุณที่ใช้มุมมองนั้นเล็กมาก

แก้ไข:

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

โดยทั่วไปคุณจะต้องชั่งน้ำหนักประสิทธิภาพเทียบกับสติ บางทีคุณสามารถทำสิ่งแฟนซีทุกชนิดเพื่อเพิ่มประสิทธิภาพของฐานข้อมูล แต่ถ้ามันหมายความว่ามันเป็นฝันร้ายสำหรับคนใหม่ที่จะครอบครอง / ดูแลรักษามันคุ้มค่าจริง ๆ ไหม? มันคุ้มกับคนที่แต่งตัวประหลาดคนใหม่ที่ต้องเล่น whack-a-mole หรือไม่เพื่อค้นหาข้อความค้นหาทั้งหมดที่จำเป็นต้องเปลี่ยนตรรกะของพวกเขา (และเสี่ยงที่เขาจะลืม / อ้วน - นิ้ว) พวกเขา b / c ตัดสินใจว่ามุมมอง "แย่" และ ไม่รวมตรรกะทางธุรกิจหลักบางอย่างเป็นสิ่งที่สามารถใช้ในการค้นหาอื่น ๆ ได้ 100 รายการใช่หรือไม่ มันขึ้นอยู่กับธุรกิจของคุณและทีม IT / IS / DB ของคุณ แต่ฉันต้องการความชัดเจนและการรวมแหล่งเดียวมากกว่าประสิทธิภาพ

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

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

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

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