Apa konvensi penamaan Anda untuk prosedur tersimpan? [Tutup]

Saya telah melihat berbagai aturan untuk penamaan prosedur yang tersimpan.

Beberapa orang mengawali nama sproc dengan usp_, yang lain dengan singkatan nama aplikasi, dan yang lainnya dengan nama pemilik. Anda tidak boleh menggunakan sp_ di SQL Server kecuali Anda bersungguh-sungguh.

Beberapa memulai nama proc dengan kata kerja (Dapatkan, Tambah, Simpan, Hapus). Lainnya menekankan nama entitas.

Pada database dengan ratusan sprocs, akan sangat sulit untuk menggulir dan menemukan sproc yang sesuai ketika Anda mengira sproc sudah ada. Konvensi penamaan dapat mempermudah pencarian sproc.

Apakah Anda menggunakan konvensi penamaan? Harap jelaskan, dan jelaskan mengapa Anda lebih menyukainya daripada pilihan lain.

Ringkasan balasan:

• Semua orang tampaknya menganjurkan konsistensi penamaan, bahwa mungkin lebih penting bagi setiap orang untuk menggunakan konvensi penamaan yang sama daripada yang mana yang digunakan.
• Awalan: Meskipun banyak orang menggunakan usp_ atau sesuatu yang serupa (tetapi jarang sp_), banyak orang lain menggunakan database atau nama aplikasi. Satu DBA pintar menggunakan gen, rpt dan tsk untuk membedakan kecambah CRUD umum dari yang digunakan untuk pelaporan atau tugas.
• Kata kerja + Kata benda tampaknya sedikit lebih populer daripada Kata Benda + Kata Kerja. Beberapa orang menggunakan kata kunci SQL (Pilih, Sisipkan, Perbarui, Hapus) untuk kata kerja, sementara yang lain menggunakan kata kerja non-SQL (atau singkatan untuk mereka) seperti Dapatkan dan Tambah. Beberapa membedakan antara kata benda tunggal dan jamak untuk menunjukkan apakah satu atau banyak catatan sedang diambil.
• Frasa tambahan disarankan di bagian akhir, jika sesuai. GetCustomerById, GetCustomerBySaleDate.
• Beberapa orang menggunakan garis bawah di antara segmen nama, dan beberapa menghindari garis bawah. app_ Get_Customer vs. appGetCustomer - Saya rasa ini masalah keterbacaan.
• Koleksi besar sprocs dapat dipisahkan menjadi paket Oracle atau solusi dan proyek Management Studio (SQL Server), atau skema SQL Server.
• Singkatan yang tidak dapat dipahami harus dihindari.

Mengapa saya memilih jawaban yang saya lakukan: Ada begitu banyak tanggapan yang baik. Terima kasih semua! Seperti yang Anda lihat, akan sangat sulit untuk memilih hanya satu. Yang saya pilih beresonansi dengan saya. Saya telah mengikuti jalan yang sama yang dia jelaskan - mencoba menggunakan Kata Kerja + Kata Benda dan kemudian tidak dapat menemukan semua kecambah yang berlaku untuk Pelanggan.

Mampu menemukan sproc yang ada, atau untuk menentukan apakah ada, sangat penting. Masalah serius bisa muncul jika seseorang secara tidak sengaja membuat sproc duplikat dengan nama lain.

Karena saya biasanya mengerjakan aplikasi yang sangat besar dengan ratusan sprocs, saya memiliki preferensi untuk metode penamaan yang paling mudah ditemukan. Untuk aplikasi yang lebih kecil, saya mungkin menganjurkan Verb + Noun, karena mengikuti konvensi pengkodean umum untuk nama metode.

Dia juga menganjurkan penggunaan awalan dengan nama aplikasi, bukan usp_ yang tidak terlalu berguna. Seperti yang ditunjukkan beberapa orang, terkadang database berisi sprocs untuk beberapa aplikasi. Jadi, mengawali dengan nama aplikasi membantu memisahkan sprocs DAN membantu DBA dan lainnya untuk menentukan aplikasi mana sproc digunakan.

Untuk proyek terakhir saya, saya menggunakan usp_ [Tindakan] [Objek] [Proses] jadi misalnya, usp_AddProduct atau usp_GetProductList, usp_GetProductDetail. Namun sekarang database ada pada 700 prosedur ditambah, menjadi jauh lebih sulit untuk menemukan semua prosedur pada objek tertentu. Misalnya saya sekarang harus mencari 50 prosedur Tambah ganjil untuk Produk tambah, dan 50 ganjil untuk Dapatkan dll.

Karena ini di aplikasi baru saya, saya berencana mengelompokkan nama prosedur berdasarkan objek, saya juga membatalkan usp karena saya merasa itu agak berlebihan, selain memberi tahu saya itu prosedur, sesuatu yang dapat saya kurangi dari nama prosedur itu sendiri.

Format barunya adalah sebagai berikut

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Ini membantu mengelompokkan berbagai hal agar lebih mudah ditemukan nanti, terutama jika ada banyak tunas.

Mengenai di mana lebih dari satu objek digunakan, saya menemukan bahwa sebagian besar instance memiliki objek primer dan sekunder, jadi objek utama digunakan dalam instance normal, dan objek sekunder dirujuk di bagian proses, misalnya App_Product_AddAttribute.

Berikut adalah beberapa klarifikasi tentang masalah awalan sp_ di SQL Server.

Prosedur tersimpan dengan awalan sp_ adalah sprocs sistem yang disimpan dalam database Master.

Jika Anda memberi sproc awalan ini, SQL Server akan mencarinya di database Master terlebih dahulu, lalu database konteks, sehingga membuang-buang resource secara tidak perlu. Dan, jika sproc yang dibuat pengguna memiliki nama yang sama dengan sproc sistem, sproc yang dibuat oleh pengguna tidak akan dijalankan.

Awalan sp_ menunjukkan bahwa sproc dapat diakses dari semua database, tetapi harus dijalankan dalam konteks database saat ini.

Berikut penjelasan yang bagus, yang mencakup demo kinerja hit.

Berikut sumber bermanfaat lain yang disediakan oleh Ant dalam komentar.

Sistem Hungarian (seperti awalan "usp" di atas) membuat saya bergidik.

Kami berbagi banyak prosedur tersimpan di berbagai database yang memiliki struktur serupa, jadi untuk database khusus, kami menggunakan awalan dari nama database itu sendiri; prosedur bersama tidak memiliki awalan. Saya kira menggunakan skema yang berbeda mungkin menjadi alternatif untuk menghilangkan awalan yang agak jelek sama sekali.

Nama sebenarnya setelah awalan hampir tidak berbeda dari penamaan fungsi: biasanya kata kerja seperti "Add", "Set", "Generate", "Calculate", "Delete", dll., Diikuti oleh beberapa kata benda yang lebih spesifik seperti "User "," DailyRevenues ", dan seterusnya.

Menanggapi komentar Ant:

1. Perbedaan antara tabel dan tampilan relevan bagi mereka yang mendesain skema database, bukan mereka yang mengakses atau mengubah kontennya. Dalam kasus langka yang membutuhkan spesifikasi skema, cukup mudah untuk menemukannya. Untuk kueri SELECT kasual, ini tidak relevan. Faktanya, saya menganggap dapat memperlakukan tabel dan tampilan sama sebagai keuntungan besar.
2. Tidak seperti fungsi dan prosedur tersimpan, nama tabel atau tampilan tidak mungkin dimulai dengan kata kerja, atau apa pun kecuali satu atau beberapa kata benda.
3. Sebuah fungsi membutuhkan prefiks skema untuk dipanggil. Faktanya, sintaks panggilan (yang kami gunakan, bagaimanapun) sangat berbeda antara fungsi dan prosedur tersimpan. Tetapi bahkan jika tidak, sama seperti 1. akan berlaku: jika saya dapat memperlakukan fungsi dan prosedur tersimpan yang sama, mengapa saya tidak?

Saya telah menggunakan hampir semua sistem yang berbeda selama bertahun-tahun. Saya akhirnya mengembangkan yang ini, yang terus saya gunakan hari ini:

Awalan:

• gen - Umum: CRUD, kebanyakan
• rpt - Laporan: cukup jelas
• tsk - Tugas: biasanya sesuatu dengan logika prosedural, dijalankan melalui pekerjaan terjadwal

Penentu Tindakan:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(Dalam kasus di mana prosedur melakukan banyak hal, keseluruhan sasaran digunakan untuk memilih penentu tindakan. Misalnya, pelanggan INSERT mungkin memerlukan banyak pekerjaan persiapan, tetapi sasaran keseluruhan adalah INSERT, jadi "Ins" dipilih.

Obyek:

Untuk gen (CRUD), ini adalah tabel atau nama tampilan yang terpengaruh. Untuk rpt (Report), berikut adalah deskripsi singkat dari report tersebut. Untuk tsk (Task) ini adalah deskripsi singkat dari tugas tersebut.

Penjelas Opsional:

Ini adalah bit informasi opsional yang digunakan untuk meningkatkan pemahaman tentang prosedur. Contohnya termasuk "Oleh", "Untuk", dll.

Format:

[Awalan] [Penentu Tindakan] [Entitas] [Penjelas Opsional]

Contoh nama prosedur:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Daftar pelanggan

• UserPreference_DeleteByUserID

Tidak ada awalan atau omong kosong Hongaria yang konyol. Hanya nama tabel yang paling terkait dengannya, dan deskripsi singkat tentang fungsinya.

Satu peringatan untuk hal di atas: Saya pribadi selalu mengawali semua CRUD saya yang dibuat secara otomatis dengan zCRUD_ sehingga memilah ke akhir daftar di mana saya tidak perlu melihatnya.

Memulai nama prosedur tersimpan dengan sp_buruk di SQL Server karena sistem sprocs semua dimulai dengan sp_. Penamaan yang konsisten (bahkan sebatas hobgoblin-dom) berguna karena memfasilitasi tugas otomatis berdasarkan kamus data. Awalan sedikit kurang berguna di SQL Server 2005 karena mendukung skema, yang dapat digunakan untuk berbagai jenis ruang nama dengan cara yang digunakan untuk prefiks pada nama. Misalnya, pada skema bintang, seseorang dapat memiliki skema redup dan fakta dan merujuk ke tabel berdasarkan konvensi ini.

Untuk prosedur tersimpan, prefiks berguna untuk tujuan mengidentifikasi sprocs aplikasi dari sprocs sistem. up_vs. sp_membuatnya relatif mudah untuk mengidentifikasi prosedur tersimpan non-sistem dari kamus data.

Saya selalu merangkum prosedur yang tersimpan dalam paket (saya menggunakan Oracle, di tempat kerja). Itu akan mengurangi jumlah objek terpisah dan kode bantuan digunakan kembali.

Konvensi penamaan adalah masalah selera dan sesuatu yang harus Anda setujui dengan semua pengembang lain saat proyek dimulai.

untuk database kecil, saya menggunakan uspTableNameOperationName, misalnya uspCustomerCreate, uspCustomerDelete, dll. Ini memfasilitasi pengelompokan berdasarkan entitas 'utama'.

untuk database yang lebih besar, tambahkan skema atau nama subsistem, misalnya Menerima, Membeli, dll. agar mereka tetap dikelompokkan bersama (karena sql server suka menampilkannya sesuai abjad)

saya mencoba untuk menghindari singkatan pada nama, untuk kejelasan (dan orang baru di proyek tidak perlu bertanya-tanya apa kepanjangan dari 'UNAICFE' karena sprocnya bernama uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Saat ini saya menggunakan format seperti berikut ini

Notasi:

[PREFIX] [APLIKASI] [MODUL] _ [NAMA]

Contoh:

P_CMS_USER_UserInfoGet

Saya suka notasi ini karena beberapa alasan:

• dimulai dengan Awalan yang sangat sederhana memungkinkan kode ditulis untuk hanya mengeksekusi objek yang dimulai dengan awalan (untuk mengurangi injeksi SQL, misalnya)
• di lingkungan kami yang lebih besar, beberapa tim sedang mengerjakan aplikasi berbeda yang menjalankan arsitektur database yang sama. Notasi Aplikasi menunjukkan grup mana yang memiliki SP.
• Bagian Module dan Name hanya melengkapi heirarki. Semua nama harus dapat dicocokkan dengan Grup / Aplikasi, Modul, Fungsi dari heirarki.

Saya selalu menggunakan:

usp [Nama Tabel] [Tindakan] [Detail Tambahan]

Diberikan tabel bernama "tblUser", yang memberi saya:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Prosedurnya diurutkan menurut abjad berdasarkan nama tabel dan fungsionalitas, jadi mudah untuk melihat apa yang dapat saya lakukan pada tabel tertentu. Menggunakan awalan "usp" memberi tahu saya apa yang saya panggil jika saya (misalnya) menulis prosedur 1000-baris yang berinteraksi dengan prosedur lain, beberapa tabel, fungsi, tampilan, dan server.

Sampai editor di SQL Server IDE sebagus Visual Studio saya tetap awalan.

application prefix_ operation prefix_ description of database object yang terlibat (minus spasi di antara garis bawah - harus memberi spasi agar mereka muncul) .

awalan operasi yang kami gunakan -

• “ Dapatkan " - mengembalikan kumpulan data
• “ Ins ” - menyisipkan data
• “ Upd " - memperbarui data
• " Del " - menghapus data

misalnya

wmt_ in _ customer _details

"alat manajemen tenaga kerja, masukkan detail ke tabel pelanggan"

keuntungan

Semua prosedur tersimpan yang berkaitan dengan aplikasi yang sama dikelompokkan berdasarkan nama. Di dalam grup, prosedur tersimpan yang menjalankan jenis operasi yang sama (mis. Penyisipan, pembaruan, dll.) Dikelompokkan bersama.

Sistem ini bekerja dengan baik untuk kami, memiliki kira-kira. 1000 prosedur yang tersimpan dalam satu database di atas kepala saya.

Sejauh ini, belum menemukan kerugian dari pendekatan ini.

GetXXX - Mendapat XXX berdasarkan @ID

GetAllXXX - Mendapat semua XXX

PutXXX - Sisipkan XXX jika diteruskan @ID adalah -1; pembaruan lain

DelXXX - Menghapus XXX berdasarkan @ID

Saya pikir konvensi penamaan usp_ tidak ada gunanya bagi siapa pun.

Di masa lalu, saya telah menggunakan Get / Update / Insert / Delete prefiks untuk operasi CRUD, tetapi sekarang karena saya menggunakan Linq ke SQL atau EF untuk melakukan sebagian besar pekerjaan CRUD saya, ini sepenuhnya hilang. Karena saya memiliki begitu sedikit procs yang tersimpan di aplikasi baru saya, konvensi penamaan tidak lagi penting seperti dulu ;-)

Untuk saat ini, aplikasi yang sedang saya kerjakan, kami memiliki awalan yang mengidentifikasi nama aplikasi (empat huruf kecil). Alasannya adalah aplikasi kita harus dapat hidup berdampingan dengan aplikasi lama dalam database yang sama, jadi awalan adalah suatu keharusan.

Jika kami tidak memiliki batasan lama, saya yakin kami tidak akan menggunakan awalan.

Setelah awalan kami biasanya memulai nama SP dengan kata kerja yang menjelaskan apa yang dilakukan prosedur, dan kemudian nama entitas tempat kami beroperasi. Pluralisasi nama entitas diperbolehkan - Kami mencoba menekankan keterbacaan, sehingga jelas apa yang dilakukan prosedur dari namanya saja.

Nama prosedur tersimpan yang umum di tim kami adalah:

shopGetCategories
shopUpdateItem

Menurut saya tidak terlalu penting apa prefiks Anda selama Anda logis dan konsisten. Secara pribadi saya gunakan

spu_ [deskripsi tindakan] [deskripsi proses]

di mana deskripsi tindakan adalah salah satu dari rangkaian kecil tindakan umum seperti dapatkan, setel, arsipkan, sisipkan, hapus, dll. Deskripsi proses adalah sesuatu yang singkat tapi deskriptif, misalnya

spu_archiveCollectionData 

atau

spu_setAwardStatus

Saya menamai fungsi saya dengan cara yang sama, tetapi awalan dengan udf_

Saya telah melihat orang-orang mencoba menggunakan notasi pseudo-Hungaria untuk penamaan prosedur, yang menurut saya menyembunyikan lebih dari yang diungkapkan. Selama ketika saya membuat daftar prosedur saya menurut abjad, saya dapat melihatnya dikelompokkan berdasarkan fungsionalitas, maka bagi saya itu tampaknya menjadi titik manis antara keteraturan dan ketelitian yang tidak perlu

Hindari sp_ * di server SQl karena semua prosedur yang disimpan sistem dimulai dengan sp_ dan oleh karena itu akan lebih sulit bagi sistem untuk menemukan objek yang sesuai dengan namanya.

Jadi jika Anda memulai dengan sesuatu selain sp_ semuanya menjadi lebih mudah.

Jadi kami menggunakan penamaan umum Proc_ untuk memulai. Itu membuatnya lebih mudah untuk mengidentifikasi prosedur jika disajikan dengan satu file skema besar.

Selain itu kami menetapkan awalan yang mengidentifikasi fungsi tersebut. Suka

Proc_Poll_Interface, Proc_Inv_Interface dll.

Ini memungkinkan kita untuk menemukan semua procs tersimpan yang melakukan tugas POLL vs yang melakukan Inventaris, dll.

Bagaimanapun sistem awalan tergantung pada domain masalah Anda. Tapi al mengatakan dan melakukan sesuatu yang serupa harus hadir bahkan jika itu hanya untuk memungkinkan orang dengan cepat menemukan prosedur yang tersimpan di drop down explorere untuk diedit.

misalnya fungsi lainnya.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Kami mengikuti penamaan berbasis fungsi karena Procs mirip dengan kode / fungsi daripada objek statis seperti tabel. Itu tidak membantu bahwa Procs dapat bekerja dengan lebih dari satu tabel.

Jika proc melakukan lebih banyak fungsi daripada yang dapat ditangani dalam satu nama, itu berarti proc Anda melakukan jauh lebih dari yang diperlukan dan waktunya untuk membaginya lagi.

Semoga membantu.

Saya terlambat bergabung dengan utas tetapi saya ingin memasukkan balasan saya di sini:

Dalam dua proyek terakhir saya ada tren yang berbeda seperti, di salah satu kami menggunakan:

Untuk mendapatkan Data: s <tablename> _G
Untuk menghapus Data: s <tablename> _D
Untuk memasukkan Data: s <tablename> _I
Untuk memperbarui Data: s <tablename> _U

Konvensi penamaan ini juga diikuti di bagian depan dengan mengawali kata dt .

Contoh:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Dengan bantuan konvensi penamaan di atas dalam aplikasi kami, kami memiliki nama yang baik dan mudah diingat.

Sementara di proyek kedua kami menggunakan konvensi penamaan yang sama dengan perbedaan kecil:

Untuk mendapatkan Data: sp_ <tablename> G
Untuk menghapus Data: sp_ <tablename> D
Untuk memasukkan Data: sp_ <tablename> I
Untuk memperbarui Data: sp_ <tablename> U

Contoh:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU