Depolanan yordamlar için adlandırma kuralınız nedir? [kapalı]

Saklanan prosedürleri adlandırmak için çeşitli kurallar gördüm.

Bazı kişiler sproc adının önüne usp_, diğerlerine uygulama adı için bir kısaltma ve diğerlerine de bir sahip adı ekleyebilir. Gerçekten kastetmediğiniz sürece SQL Server'da sp_ kullanmamalısınız.

Bazıları proc ismine bir fiil ile başlar (Al, Ekle, Kaydet, Kaldır). Diğerleri varlık adlarını vurgular.

Yüzlerce sprocs içeren bir veritabanında, zaten var olduğunu düşündüğünüzde gezinmek ve uygun bir sproc bulmak çok zor olabilir. Adlandırma kuralları bir sproc'u bulmayı kolaylaştırabilir.

Bir adlandırma kuralı kullanıyor musunuz? Lütfen açıklayın ve neden diğer seçeneklere göre tercih ettiğinizi açıklayın.

Cevapların özeti:

• Herkes adlandırma tutarlılığını savunuyor gibi görünüyor, bu da herkesin aynı adlandırma kuralını kullanmasının belirli bir adlandırma kuralından daha önemli olabileceğini düşünüyor.
• Ön ekler: Bir çok kişi usp_ veya benzer bir şey kullanırken (ancak nadiren sp_), diğerleri veritabanı veya uygulama adını kullanır. Akıllı bir DBA, genel CRUD zincirlerini raporlama veya görevler için kullanılanlardan ayırmak için gen, rpt ve tsk kullanır.
• Fiil + İsim, İsim + Fiil'den biraz daha popüler görünüyor. Bazı kişiler fiiller için SQL anahtar kelimelerini (Seç, Ekle, Güncelle, Sil) kullanırken, diğerleri Get ve Ekle gibi SQL olmayan fiilleri (veya bunlar için kısaltmalar) kullanır. Bazıları tekli ve çoğul isimler arasında bir ya da daha fazla kaydın alınmakta olup olmadığını belirtmek için ayrım yapar.
• Sonunda, uygun olduğunda ek bir ifade önerilmektedir. GetCustomerById, GetCustomerBySaleDate.
• Bazı kişiler ad bölümleri arasında alt çizgi kullanır ve bazıları alt çizgiden kaçınır. app_ Get_Customer ve appGetCustomer karşılaştırması - Sanırım bu bir okunabilirlik meselesi.
• Büyük zincir zincirleri koleksiyonları Oracle paketlerine veya Management Studio (SQL Server) çözümlerine ve projelerine veya SQL Server şemalarına ayrılabilir.
• Anlaşılmaz kısaltmalardan kaçınılmalıdır.

Neden yaptığım yanıtı seçiyorum: ÇOK iyi yanıt var. Hepinize teşekkür ederim! Gördüğünüz gibi, sadece birini seçmek çok zor. Seçtiğim kişi benimle rezonansa girdi. Onun tanımladığı aynı yolu izledim - Fiil + İsim kullanmaya çalışıyorum ve sonra Müşteri için geçerli olan tüm dişleri bulamıyorum.

Mevcut bir sproc'u bulabilmek veya var olup olmadığını belirleyebilmek çok önemlidir. Birisi yanlışlıkla başka bir isimle yinelenen bir eşleşme yaratırsa ciddi sorunlar ortaya çıkabilir.

Genellikle yüzlerce dişli içeren çok büyük uygulamalarda çalıştığım için, bulması en kolay adlandırma yöntemini tercih ediyorum. Daha küçük bir uygulama için, yöntem adları için genel kodlama kuralını izlediği için Verb + Noun'u savunabilirim.

Ayrıca, çok kullanışlı olmayan usp_ yerine uygulama adının ön ekini savunuyor. Birkaç kişinin belirttiği gibi, bazen veritabanı birden çok uygulama için sprocs içerir. Bu nedenle, uygulama adının ön eki, zincir dişlilerinin ayrılmasına yardımcı olur VE DBA'ların ve diğerlerinin sproc'un hangi uygulama için kullanıldığını belirlemesine yardımcı olur.

Son projem için usp_ [Action] [Object] [Process] kullandım, örneğin usp_AddProduct veya usp_GetProductList, usp_GetProductDetail. Ancak şimdi veritabanı 700 prosedür artıdır, belirli bir nesne üzerinde tüm prosedürleri bulmak çok daha zor hale gelir. Örneğin, şimdi Ürün ekleme için 50 tek Ekleme prosedürü ve Get vb. İçin 50 tek ekleme prosedürü aramalıyım.

Bu nedenle yeni başvurumda prosedür isimlerini nesneye göre gruplandırmayı planlıyorum, ayrıca bana bir prosedür olduğunu söylemekten başka, biraz gereksiz olduğunu hissettiğim için usp'yi bırakıyorum, adından çıkarabileceğim bir şey prosedürün kendisi.

Yeni format aşağıdaki gibidir

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Özellikle çok miktarda dişli varsa, daha sonra daha kolay bulmak için şeyleri gruplandırmaya yardımcı olur.

Birden fazla nesnenin nerede kullanıldığı ile ilgili olarak, çoğu örneğin birincil ve ikincil bir nesneye sahip olduğunu, bu nedenle birincil nesnenin normal durumda kullanıldığını ve ikincil nesnenin işlem bölümünde, örneğin App_Product_AddAttribute olduğunu buldum.

İşte SQL Server'daki sp_ önek sorunu hakkında bazı açıklamalar.

Sp_ önekiyle adlandırılan depolanan yordamlar, Ana veritabanında depolanan sistem zincirleridir.

Sproc'unuza bu öneki verirseniz, SQL Server bunları önce Ana veritabanında, ardından bağlam veritabanında arar ve böylece kaynakları gereksiz yere israf eder. Ve kullanıcı tarafından oluşturulan sproc, bir sistem sproc ile aynı ada sahipse, kullanıcı tarafından oluşturulan sproc çalıştırılmaz.

Sp_ öneki, sproc'un tüm veritabanlarından erişilebilir olduğunu, ancak mevcut veritabanı bağlamında çalıştırılması gerektiğini belirtir.

İşte hit performansın bir demosunu içeren güzel bir açıklama.

İşte Ant tarafından bir yorumda sağlanan başka bir yardımcı kaynak.

Macarca Sistemleri (yukarıdaki "usp" öneki gibi) beni ürpertiyor.

Birçok saklı yordamı farklı, benzer şekilde yapılandırılmış veritabanları arasında paylaşıyoruz, bu nedenle veritabanına özgü olanlar için, veritabanı adının kendisinin bir önekini kullanıyoruz; paylaşılan prosedürlerin öneki yoktur. Sanırım farklı şemalar kullanmak, bu tür çirkin öneklerden tamamen kurtulmak için bir alternatif olabilir.

Önekten sonraki gerçek ad, işlev adlandırma işleminden pek farklı değildir: tipik olarak "Ekle", "Ayarla", "Oluştur", "Hesapla", "Sil" vb. Gibi bir fiil, ardından "Kullanıcı "," DailyRevenues "vb.

Ant'ın yorumuna yanıt vermek:

1. Bir tablo ile görünüm arasındaki fark, içeriğine erişen veya değiştirenlerle değil, veritabanı şemasını tasarlayanlarla ilgilidir. Şema özelliklerine ihtiyaç duyulan nadir durumlarda, bulmak yeterince kolaydır. Sıradan SEÇME sorgusu için alakasızdır. Aslında, tabloları ve görüşleri aynı şekilde ele alabilmeyi büyük bir avantaj olarak görüyorum.
2. İşlevler ve saklı yordamlardan farklı olarak, bir tablo veya görünümün adının bir fiille başlaması veya bir veya daha fazla isim dışında herhangi bir şey olması pek olası değildir.
3. Bir işlev, şema önekinin çağrılmasını gerektirir. Aslında, çağrı sözdizimi (yine de kullandığımız) bir işlev ve saklı yordam arasında çok farklıdır. Ancak olmasa bile, 1 ile aynı şey geçerli olacaktır: işlevleri ve depolanan prosedürleri aynı şekilde ele alabiliyorsam, neden yapmayayım?

Yıllar boyunca hemen hemen tüm farklı sistemleri kullandım. Sonunda bugün kullanmaya devam ettiğim bunu geliştirdim:

Önek:

• gen - Genel: CRUD, çoğunlukla
• rpt - Rapor: kendinden açıklamalı
• tsk - Görev: genellikle prosedür mantığına sahip bir şey, zamanlanmış işler aracılığıyla çalıştır

Eylem Tanımlayıcı:

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

(Prosedürün birçok şey yaptığı durumlarda, genel amaç eylem tanımlayıcısını seçmek için kullanılır. Örneğin, bir müşteri INSERT çok sayıda hazırlık çalışması gerektirebilir, ancak genel hedef INSERT'dir, bu nedenle "Ins" seçilir.

Nesne:

Gen (CRUD) için bu, etkilenen tablo veya görünüm adıdır. Rpt (Rapor) için bu, raporun kısa açıklamasıdır. Tsk (Görev) için bu, görevin kısa açıklamasıdır.

Opsiyonel Temizleyiciler:

Bunlar, prosedürün anlaşılmasını geliştirmek için kullanılan isteğe bağlı bilgi parçalarıdır. Örnekler arasında "Yazar", "İçin" vb.

Biçim:

[Önek] [Eylem Tanımlayıcı] [Varlık] [İsteğe Bağlı Açıklayıcılar]

Prosedür adlarına örnekler:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Müşteri listesi

• UserPreference_DeleteByUserID

Ön ek veya aptalca Macar saçmalığı yok. Sadece en yakın ilişkili olduğu tablonun adı ve ne işe yaradığının hızlı bir açıklaması.

Yukarıdakilere bir uyarı: Ben şahsen her zaman otomatik olarak oluşturulmuş tüm CRUD'larımı zCRUD_ ile ön ekliyorum, böylece listenin sonuna bakmak zorunda kalmayacağım.

Bir saklı yordam adı ile başlatmak sp_, SQL Server'da kötüdür çünkü sistem zincirlerinin tümü sp_ ile başlar. Tutarlı adlandırma (hobgoblin-dom kapsamında bile) kullanışlıdır çünkü veri sözlüğüne dayalı otomatikleştirilmiş görevleri kolaylaştırır. Önekler, SQL Server 2005'te, eskiden adların öneklerinde olduğu gibi çeşitli ad alanları türleri için kullanılabilen şemaları desteklediğinden biraz daha az kullanışlıdır. Örneğin, bir yıldız şemasında, dim ve olgu şemalarına sahip olunabilir ve bu kural ile tablolara başvurulabilir.

Depolanan yordamlar için ön ek, uygulama zincirlerini sistem zincirlerinden belirlemek amacıyla kullanışlıdır. up_buna kıyasla sp_, sistem dışı depolanan prosedürleri veri sözlüğünden tanımlamayı nispeten kolaylaştırır.

Saklanan prosedürleri her zaman paketler halinde özetliyorum (iş yerinde Oracle kullanıyorum). Bu, ayrı nesnelerin sayısını azaltacak ve kodun yeniden kullanılmasına yardımcı olacaktır.

Adlandırma kuralı bir zevk meselesidir ve proje başlangıcında diğer tüm geliştiricilerle aynı fikirde olmanız gereken bir konudur.

küçük veritabanları için uspTableNameOperationName kullanıyorum, örneğin uspCustomerCreate, uspCustomerDelete, vb. Bu, 'ana' varlığa göre gruplamayı kolaylaştırır.

Daha büyük veritabanları için, bunları bir arada gruplandırmak için bir şema veya alt sistem adı ekleyin, örneğin Alma, Satın Alma, vb. (çünkü sql sunucusu alfabetik olarak görüntülemeyi sever)

Açıklık için isimlerdeki kısaltmalardan kaçınmaya çalışıyorum (ve projedeki yeni insanların 'UNAICFE' ne anlama geldiğini merak etmelerine gerek yok çünkü sproc, uspUsingNoAbbreviationsIncreasesClarityForEveryone olarak adlandırılıyor)

Şu anda aşağıdaki gibi bir format kullanıyorum

Gösterim:

[ÖN EK] [UYGULAMA] [MODÜL] _ [AD]

Misal:

P_CMS_USER_UserInfoGet

Bu gösterimi birkaç nedenden dolayı seviyorum:

• çok basit Önek ile başlamak, kodun yalnızca önekle başlayan nesneleri yürütmek için yazılmasına izin verir (örneğin, SQL enjeksiyonunu azaltmak için)
• Daha geniş ortamımızda, birden çok ekip aynı veritabanı mimarisini kullanan farklı uygulamalar üzerinde çalışıyor. Uygulama gösterimi, hangi grubun SP'ye sahip olduğunu belirtir.
• Modül ve Ad bölümleri yalnızca hiyerarşiyi tamamlar. Tüm isimler, hiyerarşiden Grup / Uygulama, Modül, İşlev ile eşleştirilebilmelidir.

Ben her zaman kullanırım:

usp [Tablo Adı] [Eylem] [Ekstra Ayrıntı]

"TblUser" adlı bir tablo verildiğinde, bu bana şunu verir:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Prosedürler alfabetik olarak tablo adına ve işlevselliğe göre sıralanmıştır, bu nedenle herhangi bir tabloya ne yapabileceğimi görmek kolaydır. "Usp" önekini kullanmak, (örneğin) diğer prosedürler, çoklu tablolar, işlevler, görünümler ve sunucularla etkileşime giren 1000 satırlık bir prosedür yazıyorsam ne aradığımı bilmemi sağlar.

SQL Server IDE'deki düzenleyici Visual Studio kadar iyi olana kadar önekleri tutuyorum.

uygulama prefix_ operation prefix_ ilgili veritabanı nesnelerinin açıklaması ( altçizgiler arasındaki boşluklar eksi - görünmeleri için boşluklar koymak zorunda kaldı) .

kullandığımız işlem önekleri -

• " Get " - bir kayıt kümesi döndürür
• " İns " - verileri ekler
• " Upd " - verileri günceller
• " Del " - verileri siler

Örneğin

wmt_ ins _ müşteri _details

"işgücü yönetimi aracı, ayrıntıları müşteri tablosuna ekleyin"

avantajları

Aynı uygulama ile ilgili tüm saklanan prosedürler ada göre gruplandırılır. Grup içinde, aynı tür işlemi gerçekleştiren (örn. Ekler, güncellemeler, vb.) Depolanan prosedürler birlikte gruplanır.

Bu sistem bizim için yakl. Aklıma gelen tek bir veritabanında 1000 saklı prosedür.

Şimdiye kadar bu yaklaşımda herhangi bir dezavantajla karşılaşmadım.

GetXXX - @ ID'ye göre XXX alır

GetAllXXX - Tüm XXX'i alır

PutXXX - Geçilen @ ID -1 ise XXX ekler; başka güncellemeler

DelXXX - @ID'ye göre XXX'i siler

Usp_ adlandırma kuralının kimseye bir faydası olmadığını düşünüyorum.

Geçmişte, CRUD işlemleri için Get / Update / Insert / Delete öneklerini kullandım, ancak şimdi CRUD çalışmalarımın çoğunu yapmak için Linq to SQL veya EF kullandığım için bunlar tamamen ortadan kalktı. Yeni uygulamalarımda çok az depolanmış işlem olduğu için, adlandırma kuralları artık eskisi gibi önemli değil ;-)

Üzerinde çalıştığım mevcut uygulama için, uygulama adını tanımlayan bir ön ekimiz var (dört küçük harf). Bunun nedeni, uygulamamızın aynı veritabanında eski bir uygulamayla birlikte var olabilmesi gerektiğidir, bu nedenle önek bir zorunluluktur.

Eski kısıtlamaya sahip olmasaydık, bir önek kullanmayacağımızdan oldukça eminim.

Önekten sonra genellikle SP ismine prosedürün ne yaptığını ve ardından üzerinde çalıştığımız varlığın adını açıklayan bir fiil ile başlarız. Varlık adının çoğullaştırılmasına izin verilir - Prosedürün yalnızca addan ne yaptığını açıkça görebilmesi için okunabilirliği vurgulamaya çalışırız.

Ekibimizdeki tipik saklı yordam adları şöyle olacaktır:

shopGetCategories
shopUpdateItem

Mantıklı ve tutarlı olduğunuz sürece önekinizin ne olduğunun gerçekten önemli olduğunu sanmıyorum. Şahsen kullanıyorum

spu_ [eylem açıklaması] [işlem açıklaması]

burada eylem açıklaması alma, ayarlama, arşivleme, ekleme, silme vb. gibi küçük bir tipik eylemler aralığından biridir. Süreç açıklaması kısa ama açıklayıcıdır, örneğin

spu_archiveCollectionData 

veya

spu_setAwardStatus

İşlevlerimi benzer şekilde adlandırıyorum, ancak udf_ ön eki

İnsanların prosedür adlandırma için sözde Macar notasyonu kullanmaya teşebbüs ettiklerini gördüm, ki bence bu açıkladığından daha fazlasını gizliyor. Prosedürlerimi alfabetik olarak listelediğim sürece, onları işlevselliğe göre gruplanmış olarak görebilirim, o zaman benim için bu, sıra ile gereksiz titizlik arasındaki tatlı nokta gibi görünüyor

SQl sunucusunda sp_ * kullanmaktan kaçının çünkü tüm sistem depolanan prosedürler sp_ ile başlar ve bu nedenle sistemin isme karşılık gelen nesneyi bulması daha zor hale gelir.

Yani sp_ dışında bir şeyle başlarsanız işler daha kolay hale gelir.

Bu nedenle, başlangıçta ortak bir Proc_ adlandırma kullanıyoruz. Bu, büyük bir şema dosyasıyla sunulduğunda prosedürleri tanımlamayı kolaylaştırır.

Bunun dışında, işlevi tanımlayan bir önek atıyoruz. Sevmek

Proc_Poll_Interface, Proc_Inv_Interface vb.

Bu, POLL işini yapan ve Envanter vb. Yapan tüm depolanmış işlemleri bulmamızı sağlar.

Her neyse, önek sistemi sorun etki alanınıza bağlıdır. Ancak, benzer bir şeyin, yalnızca insanların explorere açılır listesindeki saklı yordamı düzenleme için hızlı bir şekilde bulmasına izin vermek için olsa bile mevcut olması gerektiğini söyledi ve yaptı.

diğer örneğin işlevi.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Fonksiyon tabanlı isimlendirmeyi takip ettik coz Procs, tablolar gibi statik nesnelerden ziyade koda / işleve benzer. Procs'un birden fazla tabloyla çalışmasına yardımcı olmaz.

Proç, tek bir adda ele alınabilecek olandan daha fazla işlev gerçekleştirdiyse, bu, proc'unuzun gereğinden çok daha fazlasını yaptığı ve bunları yeniden bölme zamanı olduğu anlamına gelir.

Umarım yardımcı olur.

Konuya geç katıldım ama cevabımı buraya girmek istiyorum:

Son iki projemde kullandığımız gibi farklı trendler var:

Verileri almak
için: s <tablename> _G Verileri silmek için: s <tablename> _D
Data eklemek için: s <tablename> _I
Verileri güncellemek için: s <tablename> _U

Bu adlandırma kurallarını, ön uçta dt kelimesinin önüne ekleyerek takip eder .

Misal:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Uygulamamızdaki yukarıdaki adlandırma kurallarının yardımıyla iyi ve hatırlanması kolay adlara sahibiz.

İkinci projede, lill farkıyla aynı adlandırma kurallarını kullandık:

Veri almak için: sp_ <tablename> G
Verileri silmek için: sp_ <tablename> D
Veri eklemek için: sp_ <tablename> I
Verileri güncellemek için: sp_ <tablename> U

Misal:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU