Apa gunanya skema SQL Server?


185

Saya bukan pemula untuk menggunakan database SQL, dan khususnya SQL Server. Namun, saya terutama orang SQL 2000 dan saya selalu bingung dengan skema di tahun 2005+. Ya, saya tahu definisi dasar skema, tetapi untuk apa mereka benar-benar digunakan dalam penyebaran SQL Server?

Saya selalu menggunakan skema default. Mengapa saya ingin membuat skema khusus? Mengapa saya harus menetapkan skema bawaan apa saja?

EDIT: Untuk memperjelas, saya kira saya sedang mencari manfaat skema. Jika Anda hanya akan menggunakannya sebagai skema keamanan, sepertinya peran basis data sudah mengisi peran itu ... eh ... um. Dan menggunakannya sebagai specifier namespace sepertinya adalah sesuatu yang bisa Anda lakukan dengan kepemilikan (dbo versus pengguna, dll.).

Saya kira apa yang saya maksudkan adalah, apa yang dilakukan Schemas yang tidak dapat Anda lakukan dengan pemilik dan peran? Apa manfaat spesifik mereka?

Jawaban:


164

Skema secara logis mengelompokkan tabel, prosedur, pandangan bersama. Semua objek terkait karyawan dalam employeeskema, dll.

Anda juga dapat memberikan izin hanya untuk satu skema, sehingga pengguna hanya dapat melihat skema yang mereka akses dan tidak ada yang lain.


21
Kemungkinan untuk menetapkan izin ke skema membuatnya layak dari perspektif administrasi.
Hakan Winther

9
Tidak bisakah Anda menggunakan database terpisah?
sam yi

7
Izin skema ini kedengarannya bagus di atas kertas ... tetapi jarang digunakan dengan benar. Bagi saya itu tidak sepadan dengan masalahnya.
sam yi

3
Tetapi jika itu masalahnya, tidak bisakah Anda mencapai hal yang sama menggunakan konvensi penamaan? Saya tidak menyarankan TIDAK ada use case untuk itu; ini, lebih sering daripada tidak, merupakan tambahan dengan pengurangan.
sam yi

6
@ Ajedi32, yeah ... dengan skema Anda bisa mendapatkan komit atom tunggal dalam log transaksi tunggal dan kembali semua data Anda dalam satu tembakan versus memiliki dua database yang tidak sinkron serta memerangi transaksi yang didistribusikan.
Matthew Whited

31

Sama seperti Namespace dari kode C #.


16
Sayangnya , skema dan ruang nama .NET tidak bermain dengan sangat baik dari perspektif ORM ( yaitu Entity Framework ). Tabel dalam MyDatabase.MySchemaskema tidak secara ajaib memetakan ke kelas entitas di MyProject.MyDatabase.MySchemanamespace. Perlu dicatat juga bahwa .peretasan titik-notasi ( ) pada nama tabel akan berakhir dengan garis bawah ( _) pada nama-nama kelas. Hanya makanan untuk pikiran malang.
Dan Lugg

2
Analogi yang bagus untuk mengajar. Saya tidak melihatnya diambil 100% secara harfiah ... (peringatan itu terdengar kecil dalam praktik)
Samantha Branham

6
Secara pribadi, saya berharap mereka yang lebih seperti NET ruang nama, seperti yang satu bisa sarang jumlah sewenang-wenang skema ( yang Anda bisa dengan ruang nama ) untuk tujuan organisasi. Itu, dan saya berharap mereka akan memetakan lebih baik di EF.
Dan Lugg

Mereka tidak seperti ruang nama dalam bahasa apa pun yang dapat saya pikirkan.
Tanveer Badar

29

Mereka juga dapat memberikan semacam penamaan perlindungan tabrakan untuk data plugin. Misalnya, fitur Ubah Data Capture baru di SQL Server 2008 menempatkan tabel yang digunakannya dalam skema cdc terpisah. Dengan cara ini, mereka tidak perlu khawatir tentang konflik penamaan antara tabel CDC dan tabel nyata yang digunakan dalam database, dan dalam hal ini dapat dengan sengaja membayangi nama-nama tabel nyata.


17

Saya tahu ini adalah utas lama, tetapi saya sendiri hanya melihat skema dan berpikir berikut ini bisa menjadi kandidat lain yang baik untuk penggunaan skema:

Di Datawarehouse, dengan data yang berasal dari sumber yang berbeda, Anda dapat menggunakan skema berbeda untuk setiap sumber, dan kemudian mis mengontrol akses berdasarkan skema. Juga hindari tabrakan penamaan yang mungkin antara berbagai sumber, seperti poster lain menjawab di atas.


9

Jika Anda menjaga skema Anda tetap terpisah, maka Anda dapat mengatur skala aplikasi dengan menggunakan skema yang diberikan ke server DB baru. (Ini mengasumsikan Anda memiliki aplikasi atau sistem yang cukup besar untuk memiliki fungsi yang berbeda).

Contoh, pertimbangkan sistem yang melakukan pencatatan. Semua tabel logging dan SP berada dalam skema [logging]. Logging adalah contoh yang baik karena jarang (jika pernah) bahwa fungsionalitas lain dalam sistem akan tumpang tindih (yang bergabung) objek dalam skema logging.

Petunjuk untuk menggunakan teknik ini - memiliki string koneksi yang berbeda untuk setiap skema dalam aplikasi / sistem Anda. Kemudian Anda menyebarkan elemen skema ke server baru dan mengubah string koneksi Anda saat Anda perlu skala.


8

Saya cenderung setuju dengan Brent untuk yang ini ... lihat diskusi ini di sini. http://www.brentozar.com/archive/2010/05/why-use-schemas/

Singkatnya ... skema tidak terlalu berguna kecuali untuk kasus penggunaan yang sangat spesifik. Membuat semuanya berantakan. Jangan menggunakannya jika Anda bisa membantu. Dan cobalah untuk mematuhi aturan K (eep) I (t) S (imple) S (tupid).


2
Saya tidak berpikir bahwa Brent berpendapat bahwa "skema itu buruk", hanya saja menggunakan skema non-standar jauh lebih kompleks daripada hanya menggunakan skema default. Penjumlahan Anda selanjutnya akurat.
Joseph Daigle

"Jika [skema] digunakan dengan benar, mereka membiarkanmu memisahkan izin berdasarkan kelompok objek." ~ brentozar.com/archive/2010/05/why-use-schemas
LL Learner

7

Saya tidak melihat manfaatnya dalam mengasingkan pengguna yang terkait dengan Schemas. Inilah sebabnya ....

Sebagian besar orang menghubungkan akun pengguna mereka ke database melalui peran pada awalnya, Segera setelah Anda menetapkan pengguna ke sysadmin, atau peran database db_owner, dalam bentuk apa pun, akun itu dapat dialihkan ke akun pengguna "dbo", atau telah penuh izin pada basis data. Setelah itu terjadi, tidak peduli bagaimana Anda menetapkan diri Anda pada skema di luar skema default Anda (yang memiliki nama yang sama dengan akun pengguna Anda), hak-hak dbo tersebut ditugaskan untuk objek yang Anda buat di bawah pengguna dan skema Anda. Agak sia-sia ..... dan hanya namespace dan membingungkan kepemilikan yang sebenarnya pada objek-objek itu. Desainnya buruk jika Anda bertanya kepada saya .... siapa pun yang mendesainnya.

Apa yang seharusnya mereka lakukan adalah menciptakan "Grup", dan membuang skema dan peran dan hanya memungkinkan Anda untuk menyusun grup grup dalam kombinasi apa pun yang Anda suka, kemudian pada setiap tingkat memberi tahu sistem jika izin diwariskan, ditolak, atau ditimpa dengan kebiasaan yang Ini akan menjadi jauh lebih intuitif dan memungkinkan DBA untuk lebih mengontrol siapa pemilik sebenarnya pada benda-benda itu. Sekarang ini tersirat dalam kebanyakan kasus pengguna SQL Server dbo default memiliki hak-hak .... bukan pengguna.


7

Di toko ORACLE tempat saya bekerja selama bertahun-tahun, skema digunakan untuk merangkum prosedur (dan paket) yang diterapkan pada berbagai aplikasi front-end. Skema 'API' yang berbeda untuk setiap aplikasi sering kali masuk akal karena kasus penggunaan, pengguna, dan persyaratan sistem sangat berbeda. Misalnya, satu skema 'API' adalah untuk aplikasi pengembangan / konfigurasi hanya untuk digunakan oleh pengembang. Skema 'API' lain adalah untuk mengakses data klien melalui tampilan dan prosedur (pencarian). Skema 'API' lain mengenkapsulasi kode yang digunakan untuk menyinkronkan pengembangan / konfigurasi dan data klien dengan aplikasi yang memiliki basis datanya sendiri. Beberapa skema 'API' ini, di bawah penutup, masih akan berbagi prosedur dan fungsi umum dengan satu sama lain (melalui 'UMUM' lainnya

Saya akan mengatakan bahwa tidak memiliki skema mungkin bukan akhir dari dunia, meskipun itu bisa sangat membantu. Sungguh, itu adalah kurangnya paket di SQL Server yang benar-benar menciptakan masalah dalam pikiran saya ... tapi itu adalah topik yang berbeda.


Dengan Oracle, karena 1 instance = 1 database = 1 lisensi untuk dibayar, orang menggunakan shemas untuk menghindari pembuatan db lain dan membayar untuk lisensi lain. Di SQl Server, 1 server dapat menangani banyak basis data.
Patrick Honorez

5

Saya pikir skema seperti banyak fitur baru (apakah untuk SQL Server atau alat perangkat lunak lain). Anda perlu hati-hati mengevaluasi apakah manfaat menambahkannya ke kit pengembangan Anda mengimbangi hilangnya kesederhanaan dalam desain dan implementasi.

Menurut saya skema seperti kira-kira setara dengan ruang nama opsional. Jika Anda berada dalam situasi di mana nama objek bertabrakan dan rincian izin tidak cukup baik, inilah alat. (Saya cenderung mengatakan bahwa mungkin ada masalah desain yang harus ditangani pada tingkat yang lebih mendasar terlebih dahulu.)

Masalahnya bisa jadi, jika ada, beberapa pengembang akan mulai menggunakannya dengan santai untuk keuntungan jangka pendek; dan begitu ada di sana itu bisa menjadi kudzu.


3

Dalam SQL Server 2000, objek yang dibuat terkait dengan pengguna tertentu, seperti jika pengguna, katakanlah Sam membuat objek, katakanlah, Karyawan, tabel itu akan muncul seperti: Sam.Employees. Bagaimana jika Sam meninggalkan perusahaan atau pindah ke area bisnis lainnya. Segera setelah Anda menghapus pengguna Sam, apa yang akan terjadi pada tabel Sam.Employees? Mungkin, Anda harus mengubah kepemilikan terlebih dahulu dari Sam.Employees menjadi dbo.Employess. Skema memberikan solusi untuk mengatasi masalah ini. Sam dapat membuat semua objeknya dalam skema seperti Emp_Schema. Sekarang, jika ia membuat objek Karyawan dalam Emp_Schema maka objek tersebut akan disebut sebagai Emp_Schema.Employees. Bahkan jika akun pengguna Sam perlu dihapus, skema tidak akan terpengaruh.


1
Ini tidak lagi benar karena ada dua versi baru sejak 2000
Hogan

0

pengembangan - masing-masing pengembang kami mendapatkan skema mereka sendiri sebagai kotak pasir untuk bermain.


29
-1 Lebih baik untuk memberikan devs seluruh salinan terpisah dari database untuk dimainkan dengan mesin mereka sendiri. Kalau tidak, mereka hanya bisa dengan aman mengubah apa yang ada dalam skema mereka. Ini mempersulit promosi untuk hidup, dan juga mempersulit pemisahan skema karena alasan lain yang dijelaskan oleh jawaban lain.
Stephen Turner

5
Saya tidak dapat berbicara untuk aplikasi yang sedang Anda kerjakan ... tetapi pengembangan Anda harus mencerminkan produksi sebanyak mungkin. Memiliki skema di dev dan bukan di prod bisa menjadi masalah.
sam yi

0

Di sini contoh implementasi yang baik dari menggunakan skema dengan SQL Server. Kami memiliki beberapa aplikasi akses ms. Kami ingin mengonversinya menjadi portal Aplikasi ASP.NET. Setiap aplikasi akses ms ditulis sebagai Aplikasi untuk portal itu. Setiap aplikasi akses ms memiliki tabel database sendiri. Beberapa dari mereka terkait, kami menempatkan mereka dalam skema SQL Server umum. Sisanya mendapatkan skema sendiri. Dengan begitu, jika kita ingin tahu tabel apa yang menjadi bagian dari Aplikasi di portal aplikasi ASP.NET yang dapat dengan mudah dinavigasi, divisualisasikan, dan dipelihara.

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.