Haruskah skema dbo dihindari?


29

Ketika datang ke skema dbo:

  • Apakah ini praktik terbaik untuk menghindari menggunakan skema dbo saat membuat objek database?
  • Mengapa skema dbo harus dihindari atau haruskah itu?
  • Pengguna basis data mana yang harus memiliki skema dbo?

Beberapa konsultan mengatakan bahwa itu adalah praktik yang baik untuk menghindari skema dbo dan selalu membuat skema yang ditetapkan pengguna dan menetapkan objek ke dalam skema ini.
jrara

Saya menemukan pernyataan ini juga dari Alexander Kuznetsov di komentar posting blog ini :
jrara

Jawaban:


22

Ini mungkin praktik yang baik karena ketika Anda memiliki pengguna lain yang menggunakan basis data, Anda ingin dapat membatasi akses mereka dengan skema. Misalnya dalam database Anda memiliki tabel berikut ini.

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

Sebagai direktur SDM saya dapat mengakses apa pun dalam HRskema, sebagai ITdirektur saya dapat melihat nama pengguna dan tingkat akses karyawan. The Engineeringdepartemen dapat melihat apa situs kerja yang aktif, dll Jika dbo adalah himpunan skema untuk semua tabel saya akan memiliki waktu yang sulit segmentasi keluar data saya dan memberikan peran akses.

Idenya, saya percaya, dalam SQL Server adalah untuk menawarkan produk yang dapat diakses dan ditanyai oleh berbagai departemen. Pada kenyataannya hanya DBA / DBDevs yang benar-benar mengakses database dan biasanya hanya menyimpan data aplikasi.

Ini juga membantu dengan keterbacaan dan pengelolaan. Pada blush on pertama saya dapat dengan mudah mengidentifikasi tabel apa yang menyimpan data apa dan bagaimana data dipisahkan.

Secara pribadi saya lebih suka mendefinisikan skema sebagai praktik umum. Ingat skema adalah yunani untuk rencana, memiliki struktur skema yang ditata membantu Anda untuk merencanakan dan mengidentifikasi data.


6

Saya pikir ini benar-benar turun ke preferensi pengguna karena tidak ada alasan teknologi nyata untuk melakukan ini. Bahkan, demi kesederhanaan, saya katakan selalu menggunakan dbo kecuali persyaratan keamanan Anda menetapkan sebaliknya. Tentu saja, Anda selalu dapat melakukannya hanya untuk tujuan organisasi juga.


1
100% di belakang pendekatan ini. Saya sering meninggalkan tabel "inti" dalam skema dbo untuk kesederhanaan dan mulai menambahkan ketika diperlukan. Biasanya skema terpisah pertama yang saya tambahkan adalah "Panggung" atau "Pementasan", untuk mengelompokkan tabel pementasan saya secara terpisah. Contoh lain adalah menambahkan data dari sumber eksternal, misalnya Twitter. Alih-alih mengawali semua tabel (mis. TwitterAccount, TwitterStatus, dll.) Saya akan membuat skema "Twitter".
robopim

5

Jika ada, dbo harus dihindari karena ini adalah standar untuk SQL Server, itu juga tidak deskriptif sama sekali. Seperti semua nama default lainnya, karena ini adalah preknown, itu membuat hidup seorang hacker jauh lebih mudah (walaupun jika mereka pada titik di mana mereka hanya mencoba mencari tahu nama skema Anda, Anda mungkin sudah borked).

Di tempat saya bekerja, kami menggunakan skema untuk membagi basis data menjadi bagian-bagian yang logis, dan memberikan izin kepada skema.

Misalnya, kami mungkin memiliki sistem inventaris dengan database. Tabel utama mungkin dalam skema inv. Jika kita mengimpor sesuatu ke dalam basis data maka skema pementasan akan digunakan sebagai bagian dari proses impor. Jika kami memiliki prosedur tersimpan sistem yang pengguna tidak perlu mengakses, kami menempatkan mereka dalam skema sp.


1
+1 untuk "hindarilah karena ini default". Memaksa pengguna untuk setidaknya memikirkannya sedikit ketika mereka membuat objek.
BradC

4

Itu sebelumnya bukan praktik terbaik karena skema disembunyikan sebelum SQL 2005, semuanya dimasukkan ke dalam skema dbo. Tim SQL Server menunjukkannya sebagai praktik terbaik dan menerbitkan artikel tentangnya: Praktik Terbaik SQL Server - Implementasi Skema Objek Database

Sejauh pertanyaan Anda yang lain tentang siapa yang harus memilikinya: skema dbo dimiliki oleh akun pengguna dbo.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.