เกณฑ์การตัดสินใจว่าเมื่อใดควรใช้ schema ที่ไม่ใช่ dbo กับฐานข้อมูลใหม่

ฉันเป็นนักพัฒนาแอปพลิเคชั่นเป็นส่วนใหญ่ แต่พบว่าตัวเองต้องทำงานฐานข้อมูลล่วงหน้าทั้งหมดสำหรับโครงการปัจจุบันของฉัน ( btw ... MS SQL Server 2008 ) เป็นการตัดสินใจครั้งแรกฉันพยายามคิดว่าจะแบ่งสถานะของฉันโดยใช้ฐานข้อมูลแยกหรือใช้โครงสร้างของแยกในฐานข้อมูลเดียวกัน ฉันอ่าน SQL Server Schema เล็กน้อยและดูเหมือนว่าเป็นวิธีธรรมชาติในการแยกโดเมนวัตถุ ( ที่ฉันชอบ ) แต่ฉันไม่แน่ใจว่าอาจมีค่าใช้จ่ายแอบแฝงกับรูปแบบนี้

อะไรคือสิ่งที่ควรนำมาใช้ในการปฏิบัติมากขึ้นเมื่อเลือกระหว่างแนวทางทั้งสองนี้ หากฉันหลีกเลี่ยงการdbo.mytableสนับสนุนmyschema.mytableฉันจะสร้างความท้าทายอื่น ๆ ( หรือปัญหา ) สำหรับสถาปัตยกรรมของฉันหรือไม่

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

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

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

ในฐานข้อมูลนั้นคุณอาจใช้หรือไม่ใช้ schema เพื่อจัดระเบียบวัตถุของคุณ

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

• การออกแบบ Schema - แนวทางปฏิบัติที่ดีที่สุด
• ฉันควรทำตามมาตรฐานใดเมื่อตั้งชื่อตารางและมุมมอง
• ใช้งานเกิน / ใช้งาน schema อย่างถูกต้อง?

สำหรับกรณีของฐานข้อมูลที่แยกต่างหากให้ดูคำตอบของ Aaronแต่สิ่งนี้ทั้งหมดขึ้นอยู่กับข้อกำหนด "การทำธุรกรรมและการอ้างอิงที่สอดคล้องกัน"

เห็นด้วยกับ @gbn ฉันออกแบบสถาปัตยกรรมโดยใช้ schemas สำหรับการแยกและฐานข้อมูลสำหรับการแยกและฉันพบว่าการใช้ฐานข้อมูลนั้นมีประโยชน์มากกว่า เหตุผลสองประการ:

1. การให้แอปของคุณเชื่อมต่อกับฐานข้อมูลเฉพาะบริบทจากนั้นเรียกใช้คิวรีเดียวกันนั้นง่ายกว่าการให้คิวรีของคุณแทรก<schema>หน้าการอ้างอิงวัตถุทั้งหมด สิ่งนี้ทำให้ตัวเองมีไดนามิก SQL จำนวนมากมีการลงชื่อเข้าใช้แอปพลิเคชันที่แตกต่างกันจำนวนมากพร้อมกับสคีมาเริ่มต้น (หมายถึงรหัสของคุณจะไม่ใช้คำนำหน้าสคีมาอาศัยสคีมาเริ่มต้นของผู้ใช้แอปพลิเคชัน หรือขั้นตอนการจัดเก็บจำนวนมากในการจัดการ (ภาพเพียงรายงานง่าย ๆ ถ้าคุณต้องการหนึ่งต่อสคีแล้วเปลี่ยนรหัสตอนนี้คุณต้องไปเปลี่ยนรหัสเดียวกันหลายครั้งหนึ่งครั้งสำหรับสคีมาแต่ละครั้ง)
2. การแยกตามฐานข้อมูลช่วยให้คุณมีความยืดหยุ่นในการย้ายฐานข้อมูลไม่ว่างไปยังที่เก็บข้อมูล / อินสแตนซ์ที่เร็วขึ้นหรือแตกต่างกันโดยไม่ต้องคัดลอกวัตถุออกจากฐานข้อมูลขนาดใหญ่ที่ครอบคลุมทั้งหมด คนส่วนใหญ่ไม่ได้คิดเกี่ยวกับเรื่องนี้ล่วงหน้ามากนัก แต่มันเป็นปัญหาระดับที่แน่นอน โดยเฉพาะอย่างยิ่งถ้าคุณมี schema เดียวที่ "เข้าครอบงำ" และต้องการทรัพยากรส่วนใหญ่บนเซิร์ฟเวอร์การแยกออกเป็นงานที่ยุ่งยากมากแม้ว่าพวกเขาจะถูกคั่นด้วยสคีมาแล้ว
3. ฐานข้อมูลแยกสามารถช่วยให้คุณมีตารางการบำรุงรักษาและการสำรองข้อมูลที่แตกต่างกันสำหรับแต่ละแผนก ฉันไม่แน่ใจว่าสิ่งที่คุณหมายถึงโดย "หารด้วยรัฐ" แต่ถ้าคุณหมายถึงการแยกลูกค้าคุณอาจมีลูกค้าที่มีข้อกำหนดที่แตกต่างกันและความอดทนที่แตกต่างกันสำหรับการสูญหายของข้อมูลการบำรุงรักษาดัชนี ฯลฯ
4. คุณอาจท้ายที่สุดกับลูกค้าที่ตามกฎหมายหรือตามนโยบายขององค์กรต้องการให้คุณเก็บข้อมูลของพวกเขาแยกต่างหากจากคนอื่น ซึ่งมักจะยอมรับได้ในระดับฐานข้อมูล แต่ระดับสคีมามักจะไม่เพียงพอ คุณอาจไม่มีลูกค้าเหล่านี้ แต่อาจกลายเป็นปัญหาที่แท้จริงได้ในภายหลังหากคุณทำ