Penggunaan berlebihan / penggunaan skema yang benar?

Setelah mengajukan pertanyaan ini pada Stackoverflow , saya bertanya-tanya di mana yang telah saya lakukan adalah praktik yang benar / terbaik.

Pada dasarnya, setiap objek yang saya buat akan menjadi skema dengan nama skema yang mencerminkan penggunaan. Misalnya, saya punya skema Auditdan Admin(antara lain).

Ini pada gilirannya tidak meninggalkan objek dbo. Apakah ini ok? Apakah ada hal lain yang perlu saya lakukan?

Skema tidak hanya alat keamanan yang hebat (yang merupakan alasan yang cukup untuk menggunakannya), tetapi mereka juga sempurna untuk pemisahan logis. Dan sepertinya ini adalah apa yang Anda latih.

Bahkan jika persyaratan saat ini tidak memerlukan keamanan khusus, katakan saja semua objek database yang terkait dengan Audit harus aman untuk peran database. Jika objek-objek ini tersebar di seluruh dboskema, maka Anda harus secara eksplisit denyizin pada objek individu. Tetapi dengan Auditskema, Anda melakukan satu denydan Anda siap.

Saya pribadi mempraktikkan penggunaan skema. Seperti semua hal dalam database, ada media yang menyenangkan. Saya tidak akan membuat skema untuk setiap aspek granular dari lapisan data. Ada skema dan pemisahan yang terlalu banyak. Tapi saya kira Anda tidak mendekati itu.

Pola tipikal adalah skema berdasarkan izin, jadi Anda harus WebGUI, Desktopdll untuk kode sehingga semua objek memiliki izin yang sama dari skema .

Jika Anda memiliki grup pengguna yang jelas maka Anda bisa mengizinkannya, tetapi Anda akan berakhir dengan izin yang tumpang tindih dan berantakan di beberapa titik. Saya cenderung menunda pemeriksaan pengguna / grup ke beberapa kode pemeriksaan di dalam dan bukan objek izin: misalkan Anda memiliki pengguna Admin dan SDM Excel: semua ini menjalankan Desktopkode.

Data biasanya dibagikan sehingga saya memiliki Dataskema, mungkin skema Historyatau Archive.

Beberapa kode tidak umum (seperti UDF atau internal proc) jadi saya akan menggunakan Helperskema untuk kode yang tidak boleh dijalankan oleh kode klien.

Akhirnya, skema seperti Stagingatau Systematau Maintenancekadang-kadang berguna.

Meskipun tidak ada objek pengguna dalam dboskema, pengguna dbomemiliki semua skema.

Tidak ada objek dalam dboskema yang baik-baik saja. Dari apa yang saya lihat itu juga tidak terlalu sering menggunakan skema - walaupun berapa banyak skema 'terlalu banyak' adalah pertanyaan yang cukup subyektif (ini sebanding dengan "Berapa banyak kelas yang harus dimiliki oleh desain OO saya?").

Satu-satunya hal lain yang saya sebutkan adalah memberikan izin pada skema daripada objek individual (pertanyaan SO Anda tidak menentukan apa-apa tentang izin).

Saya ingin menggunakan skema untuk memisahkan basis data sesuai dengan modul dan pola penggunaan. Saya menemukan itu membuatnya sangat mudah untuk memahami tabel database karena itu pemeliharaan menjadi lebih mudah. Saya memiliki tipe skema berikut dalam proyek server sql terakhir saya. LT - Tabel Pencarian

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Untuk modul besar, kami juga memisahkannya dengan skema yang lebih banyak. Misalnya modul personel terdiri lebih dari 5 modul.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Kami juga menyertakan skema seperti untuk kegiatan lain TEMP, MAINTANENCE. Di studio manajemen, Anda dapat memfilter menggunakan nama skema. Pengembang yang bertanggung jawab untuk MODULE1, memfilter menurut nama dan bekerja hampir sepanjang waktu hanya dengan tabel ini. Ini membuatnya sangat mudah bagi pengembang, DB, pendatang baru sama untuk memahami tabel database.

Praktik terbaik mungkin berbeda untuk server sql daripada untuk oracle namun pengalaman saya adalah bahwa semakin sedikit skema, semakin baik.
Saya suka memiliki skema untuk dba / programmer yang memiliki hak istimewa dan beberapa kode untuk melakukan pemeliharaan. Semua data bisnis harus dimasukkan dalam satu skema sehingga Anda tahu di mana itu. Konvensi penamaan cukup untuk membedakan antara penggunaan tabel atau kode yang disimpan.
Saya dapat melihat kasus di mana Anda memiliki beberapa unit bisnis karena data yang berbeda dengan sedikit tumpang tindih masing-masing memiliki skema sendiri. Kalau tidak sederhana saja.