การใช้ schema แยกกันส่งผลต่อประสิทธิภาพของ SQL Server 2008 อย่างไร


11

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

คำถามของฉันคือจะมีผลกระทบต่อประสิทธิภาพจากการใช้หลาย schema (schemae?) ตรงข้ามกับ dbo เก่าที่ดีสำหรับทุกสิ่งหรือไม่

คำตอบ:


4

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


1

ไม่มีความแตกต่างในประสิทธิภาพ อย่างไรก็ตามคุณกำลังใช้สกีมาตอนนี้ (แม้ว่าคุณจะไม่รู้)

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

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

สิ่งนี้มีผลหลายอย่าง:

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

ผลสุดท้ายที่คุณจะพบได้เท่านั้น - อย่างเจ็บปวด - เมื่อมีอะไรบางอย่างแตกสลายคือผู้ใช้ที่แตกต่างกันอาจได้รับผลลัพธ์ที่แตกต่างจากการสืบค้นที่ระบุหรือขั้นตอนการจัดเก็บ สิ่งที่ชอบselect * from foo join barอาจทำงานได้ดีสำหรับฉันในฐานะเจ้าของ db; มันอาจจะเสียสำหรับผู้ใช้jsmithที่สร้างโดยไม่ตั้งใจหรือไม่สร้างตารางชื่อfooภายใต้สคีของเขาเอง ( jsmith.foo) ในฐานข้อมูลเดียวกัน

ด้วยเหตุผลนี้เช่นกันcreateและdropข้อความสั่งควรมีคุณสมบัติ schema-qualify ชื่อของวัตถุที่ถูกสร้างขึ้นหรือลดลง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.