ควรหลีกเลี่ยง schema dbo หรือไม่

29

เมื่อพูดถึง dbo schema:

เป็นวิธีปฏิบัติที่ดีที่สุดในการหลีกเลี่ยงการใช้ dbo schema เมื่อสร้างวัตถุฐานข้อมูลหรือไม่
เหตุใดจึงควรหลีกเลี่ยงสกีมา dbo หรือควร
ผู้ใช้ฐานข้อมูลใดควรเป็นเจ้าของ dbo schema

ที่ปรึกษาบางคนกล่าวว่าเป็นวิธีปฏิบัติที่ดีในการหลีกเลี่ยง dbo schema และสร้างสกีมาที่ผู้ใช้กำหนดและกำหนด objets ให้กับสกีมาเหล่านี้

— jrara

ฉันพบคำสั่งนี้จาก Alexander Kuznetsov ในความคิดเห็นของโพสต์บล็อกนี้:

— jrara

ใช่โปรดหลีกเลี่ยงตอนนี้ dba.stackexchange.com/a/4109/630และdba.stackexchange.com/q/8511/630และstackoverflow.com/q/6502222/27535 @JNK: FYI สำหรับคุณเช่นกัน

— gbn

21

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

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

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

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

นอกจากนี้ยังช่วยในการอ่านและการจัดการ เมื่อเริ่มแรกฉันจะสามารถระบุได้อย่างง่ายดายว่าตารางเก็บข้อมูลอะไรและแยกข้อมูลอย่างไร

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

— ไรอัน
แหล่งที่มา

6

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

— Eric Humphrey - lotsahelp
แหล่งที่มา

1

100% หลังวิธีการนี้ ฉันมักจะออกจากตาราง "แกน" ใน dbo schema เพื่อความง่ายและเริ่มเพิ่มเมื่อจำเป็น โดยทั่วไปสคีมาที่แยกกันครั้งแรกที่ฉันเพิ่มคือ "สเตจ" หรือ "การจัดเตรียม" เพื่อจัดกลุ่มตารางการแสดงละครแยกต่างหาก อีกตัวอย่างหนึ่งคือการเพิ่มข้อมูลจากแหล่งภายนอกพูดใน Twitter แทนที่จะนำหน้าตารางทั้งหมด (เช่น TwitterAccount, TwitterStatus เป็นต้น) ฉันจะสร้างสคีมา "Twitter"

— robopim

5

หากมีสิ่งใดควรหลีกเลี่ยง dbo เพราะมันเป็นค่าเริ่มต้นสำหรับ SQL Server แต่ก็ไม่ได้อธิบายอะไรเลย เช่นเดียวกับชื่อเริ่มต้นอื่น ๆ เนื่องจากเป็นที่รู้จักกันดีว่ามันทำให้ชีวิตของแฮ็กเกอร์นั้นง่ายขึ้นมาก (แม้ว่าพวกเขาจะอยู่ในจุดที่พวกเขากำลังพยายามที่จะหาชื่อสคีมาของคุณ

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

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

— DForck42
แหล่งที่มา

1

+1 สำหรับ "หลีกเลี่ยงเพราะเป็นค่าเริ่มต้น" บังคับให้ผู้ใช้อย่างน้อยคิดเกี่ยวกับมันเล็กน้อยเมื่อพวกเขาสร้างวัตถุ

— BradC

4

ก่อนหน้านี้ไม่ใช่วิธีปฏิบัติที่ดีที่สุดเนื่องจาก schema นั้นถูกซ่อนไว้ก่อน SQL 2005 ทุกอย่างถูกใส่ลงใน schema dbo ทีม SQL Server แสดงว่าเป็นแนวปฏิบัติที่ดีที่สุดและเผยแพร่บทความเกี่ยวกับเรื่องนี้: แนวทางปฏิบัติที่ดีที่สุดของเซิร์ฟเวอร์ SQL - การใช้งานแบบแผนวัตถุฐานข้อมูล

เท่าที่คำถามอื่นของคุณเกี่ยวกับผู้ที่ควรเป็นเจ้าของ: dbo schema เป็นของบัญชีผู้ใช้ dbo

— Shawn Melton
แหล่งที่มา