Bazı Brent Ozar videolarını izliyorum ( örneğin, bunun gibi ) ve tabloların önizlemesini ‘tbl’veya ile yapmamasını önerir ‘TBL’.

İnternette bazı bloglar buldum, dokümantasyona hiçbir şey eklemediğini ve “okumak daha uzun sürüyor”.

Sorular ve düşünceler

• Bu gerçekten bir sorun mu var? Çünkü ilk dba işimden bu yana 'tbl' ile tablo ekliyorum (kıdemli DBA bana bunu organizasyon için yapmamı söyledi).
• Kurtulmam gereken bir şey mi var? Bazı testler yaptım, gerçekten büyük bir tablo kopyaladım ve 'tbl' ön ekini verdim, diğerini onsuz tutarken performans sorunu fark etmedim.

Bir zamanlar bir masam vardı ve parlak ve güzeldi. Bir organizasyon için tüm finansal işlemleri yaptı. Ve sonra içine veri yüklemeye başladık.

Mevcut ayda, değerleri diledikleri sıklıkta belirtebilir ve yeniden değerlendirebilirler. Ayın son 10 günü, sayıları -> ETL işlemlerini çalıştır -> raporları günde birkaç kez yeniden yazarlardı. Ay tamamlandıktan sonra, kitaplar mühürlenir ve değerleri değiştiremezler.

Bir finansal hizmetler şirketinin ne kadar finansal veri ürettiği şaşırtıcı ... Test veri setimizle gerçekleştiremediğimiz bir şey, verilerin hacmi ay sonundaki işlemlerini aşılmaz hale getirecekti. Yeni deneme çalıştırmasıyla değiştirmeden önce "mevcut ayın verilerini" silmek uzun zaman aldı.

Her şeyin MonthlyAllocation tablosuna bağlı olan "kim ne olduğunu bilir" başlıklı sıradışı listesini bozmadan işlemeyi daha hızlı yapmak için bir şeyler yapmak zorunda kaldık. Sihirbaz çalmaya ve masa örtüsünü altlarından fırlatmaya karar verdim. Eski okula gittim ve Bölünmüş Görünüm kullandım . Veriler zaten bir IsComplete bayrağına sahipti, bu yüzden iki tablo hazırladım - her biri aykırı denetim kısıtlamaları içeriyor: MonthlyAllocationComplete, MonthlyAllocationInComplete

Ardından bölümlenmiş görünümü orijinal tabloyla aynı adla oluşturdum: MonthlyAllocation. Veritabanında yaptığımız fiziksel değişimle ilgili hiçbir bilge hiçbir işlem değildi. Hiçbir rapor kırılmadı, doğrudan erişime sahip analistlerin hiçbiri bu "tablo" ile ilgili herhangi bir sorunu önce veya sonra bildirmedi.

Harika hikaye kardeşim, ama nereye gidiyorsun?

Ya orada adlandırma kuralları varsa, tbl_MonthlyAllocation? Şimdi ne olacak? Her ETL'den, her rapordan, organizasyondaki her bir geçici e-tablodan geçerek ve onları vw_MonthlyAllocation kullanmaları için güncelleyerek çok fazla erkek saati harcıyor muyuz? Ve sonra elbette tüm bu değişiklikler Değişim Panosundan geçer ve bu her zaman hızlı ve acısız bir işlemdir.

Patronunuz sorabilir: Şirkete yine tüm bu işler için ödül nedir?

Diğer seçenek ise, bu görüşü tbl_ olarak adlandırıyor ve tüm bu süreyi kodları test etmek, güncellemek ve dağıtmak için harcıyoruz. Bu, eğlenceli bir fıkra haline gelir ve tüm yeni işe alımlara ve dikkatleri kısa olanlara, neden nesnelerin isimlendirilmesiyle tutarsız olduğunuz konusunda veri tabanı ile çalışmak zorunda olduklarını açıklarsınız.

Ya da fazladan meta verileri olan nesneleri çift kodlamazsınız. Veri tabanı size hangi tablo olduğunu, görünümün ne olduğunu, tablo değerli fonksiyonun ne olduğunu söyler.

Adlandırma kuralları iyidir, onlarla bir köşeye kendinizi boyamayın.

Brent burada (soruda bahsettiğiniz adam).

Tablo adlarınızın önüne tbl eklememenizi söylememin nedeni, çocuğunuzun adının önüne çocuk eklememeyi söylememin aynı nedeni. Onlara John ve Jane ile çocuk deme. Sadece herhangi bir değer katmakla kalmaz, bunlar daha sonra yaşamda bir çocuk olmayabilir - ve nesneleriniz daha sonra görüş olabilir.

Bu çok öznel bir tartışma, ama işte benim görüşüm: tbl öneki faydasız.

Kaç tane senaryo koduna bakıyorsun ve bir şeyin masa mı yoksa başka bir şey olduğunu söyleyemez misin?

Nesne Gezgini'ndeki tabloların bir listesine bakarken, aradığınızı bulmak için daha fazla iş yapmanız gerekmesi dışında, tbl hangi değeri ekliyor?

Bazı insanlar bir masa veya manzara ile uğraşırken kodlarında açık olmasını istediklerini söylüyorlar. Neden? Ve eğer bu önemliyse, neden sadece görüşlerini özel bir şekilde adlandırmıyorsun? Çoğu durumda, aynı masa gibi davranırlar, bu yüzden ayırt etmede çok az değer görüyorum.

Bu korkunç bir uygulamadır.

tbl
tbl_
Table_
t_

... hepsini üretimde gördüm.

Şu anda birlikte çalıştığım ürünlerden birinde adlandırılmış tabloların tbl_whateveryarısına ve diğer yarısında "normal" olarak adlandırılıyor - Açıkçası farklı standartlarda çalışan geliştiricilere sahipler. Kötü alışkanlıklarından bir diğeri, yabancı anahtar olan sütun adlarını fk, ardından tablo adını ve fkardından sütun adını ön plana çıkarmaktır fktbl_AlarmsfkAlarmsID. Bu adlandırma kuralı, tüm tbl_%mantranın mantıklı bir uzantısıdır ve ne kadar saçma olduğunu görebilirsiniz!

Beni günlük olarak ağlatan diğer veritabanını neredeyse unutuyordum. Sütun adlarını ... önek Veritipleri dtPaymentDateadı gerçekten gerekli çünkü dtönek? `

HİÇDEN HEDEF KİŞİSELLEŞTİRMEYE HAZIRLANIN YARDIMCI YARDIM HEDEFLERI GERÇEKLEŞTİRMEN YARARLANABİLİR NABALARINIZI HAZIRLAYIN. proVANE SAHİP ÇALIŞTIRICI HAZIRLANMASI GERÇEKLEŞTİRMEN SINAVI YAZDIRMAK.

KENDİNE KARAR VERMELİ ETKİNLİK HEDEFLERİ nouPeople auxCan verDüşükleri anlayın ve nouWrite adjBetter!

Bunun gibi bir ön ek kullanmak Macar Notasyonu olarak bilinir . Bu öncül basittir: nasıl bir şey olduğunu nasıl adlandırıldığını belirleyebilirsiniz. Bu, özellikle programlama dillerinde, özellikle geliştiricilerin, beceri eksikliği veya dil özellikleri eksikliği nedeniyle düzinelerce sayfaya yayılan monolitik işlevler yazması durumunda yaygındır. Geliştiricilerin veri türlerini düz tutmasına yardımcı olan bir hatırlatıcı yardımdır.

Genel olarak konuşursak, bu adlandırma tarzının gerçekten eski kodlarda veya sadece öğrenen (ve bu alışkanlığı öğrenen) olan ya da hatırlayabildikleri kadar uzun süredir yapan geliştiriciler tarafından kullanılması muhtemeldir. Tecrübelerime göre, Macarca notasyonunun bir programlama kursu ya da öğretici tarafından tanıtılmamışlarsa, deneyimsiz geliştiricilerle kendiliğinden ortaya çıktığını görmenin nadiren olduğunu gördüm; i veya x veya acct gibi değişken isimleri kullanma olasılıkları daha yüksektir .

Kendinizi bir köşeye boyamanın yanı sıra, bu gerçekten sadece bir dolgudur. SQL sözdizimi, bir geliştiricinin bir alandan, kayıttan veya veri kümesinden (bir tablo, görünüm, vb. Olabilir) bahsediyorlarsa her zaman bilmesi gereken kesinliktedir. Mükemmel bir öğretim yardımı olsa da, bu sözdizimi genellikle üretim veritabanlarında bulunmamalıdır. Okunabilirliğe zarar verebilir ve aradığınız masayı bulmayı daha da zorlaştırabilir, özellikle tbl ve masa vs. sekmeleri gibi alternatif adlandırma temaları açılırsa , vb.

Veri tabanı tablolarınızı, alanlarınızı, vb. Dediğiniz şeyi gerçekten önemsemiyor. İnsan operatörleri veya senaryoları tarafından belirli bir düzende düzenlenmiş verilerin sadece baytları. Bununla birlikte, bu verileri sürdürmesi gereken insanlar, "kullanıcı", "düzen" ve "hesap" gibi anlamlı isimleri takdir edeceklerdir. Ayrıca, ''% 'gibi tabloyu göster' 'gibi SQL sorguları kullanıyorsanız daha pratiktir. Önekleri ve sonekleri kullanmak gereksiz yere gereksiz yere karmaşıklığı artırabilir.

Ben gibi birkaç blog postaları okudum bu ya bu (epeyce var) benim ilk SQL sunucu örneği miras ve öneki nerede, ben daha az ayrıntılı bir yaklaşım ve tekil adlandırma kuralı ile yenilerini geliştirmeye başlamak istedim sayıda nesne fark edince ( Nesne İlişkisel Haritalama üzerinde [ ve muhtemelen diğer geliştiricilerin ] çalışması için çok daha kolay .

En yaygın olarak kullanılan önekleri biri oldu Tblya tbl, ama sonra vardı TBLve tbl_hatta*TableName*_Tbl

Sorgulamaya ve Visual Studio'dan çalışmaya çalışırken, bu sadece cehennemdir, önceden ayarlanmış bir masa setinin olması önemli olmaz tblama lütfen en azından bütün Veritabanı için bu şekilde saklayın.

Sonunda kesinlikle şunu söyleyeceğim, kişisel bir tercih meselesi ancak tutarlılık ile ilgili çok fazla şey var ve eğer o yolda inerseniz, birçok insan en azından gelişiminiz boyunca aynı kaldığınız için mutlu olacak.

... Öte yandan şunu söylemek istedim, başka bir yaklaşım benimserseniz ve önek olmayan, tekil isim tablosuna giderseniz, gelecekte bir geliştiriciyi mutlu edersiniz ve mutluluktan daha önemli olan şey nedir?

Evet, nesnenin türünü belirten bir önek eklemek bir problemdir ve gereksizdir . Çünkü,

1. Bazen nesneler hayata bir şey olarak başlar, ancak başka bir şey haline gelir . (örneğin, tablo bir nedene ve nedense tblXxxbölündü tblXxxYve tblXxxZiki yeni tabloyu birleştiren bir görünümle değiştirildi. Şimdi denilen bir görünümünüz var tblXxx).
2. tblEditöre yazdığınızda , Otomatik Tamamlama özelliği 45 saniye bekler ve ardından 4000 girişin listesini gösterir.

Fakat...

Şeytanın avukatı oynayacağım ve başkalarına açıkça tavsiye ettiği bir şeyi söyleyeceğim. Bir sonek / ön ekin yararlı olabileceği bazı nadir durumlar vardır ve işte çalıştığım organizasyondan bir örnek.

İş mantığının Oracle PL / SQL'de yazıldığı varlık tabanlı bir ERP sistemimiz var. Neredeyse yirmi yıllık, ancak çok istikrarlı bir sistem (Bu eski bir sistem değil. Sürekli geliştiriyoruz).

Sistem varlık tabanlıdır ve her varlık bir tabloyu, çoklu görünümleri, çoklu PL / SQL paketlerini ve diğer veritabanı nesnelerinin bir ana bilgisayarını ilişkilendirir.

Şimdi, aynı varlığa ait nesnelerin aynı ada sahip olmasını istiyoruz, ancak bunun amacını ve türünü ayırt edebilmeyi istiyoruz. Dolayısıyla, adlandırılmış iki varlığımız varsa CustomerOrderve CustomerInvoiceaşağıdaki nesneleri alacağız:

1. Verileri depolayan tablolar [ TABsonek]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Müşteriler tarafından kullanılan görünümler [Sonek yok]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Temel işlemler için arayüz; (PL / SQL paketleri) [ APIsonek]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Rapor üreticilerine; (PL / SQL paketleri) [ RPIsonek]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Birincil anahtarlar için dizinler [ PKsonek]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. İkincil endeksler [ IXsonek]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(nerede XXXdizin kullanımını açıklar).
7. ... ve bunun gibi.

Bu aslında bir uygulama Macarca şeklidir (aynı nesne türünün amaca bağlı olarak farklı sonekleri olabileceğini unutmayın ). Ancak, önek yerine sonek ile. Bu sistemin okunması ne kadar kolay olduğunu sana yeterince söyleyemem. IntelliSense aslında işe yarıyor çünkü TBL4000 sonuç yazmak ve elde etmek yerine, Customeradlandırılmış varlıklara ait tüm nesneleri yazıp alabiliyorum Customer*.

Böylece, burada size meta verilerin ne kadar yararlı olabileceğini gösterdim . Amaç, tek bir adla tanımlanabilen ilişkili bir veritabanı nesnesi kümesine sahip olmak, ancak bunları amaçlarına göre farklılaştırmaktır .

Bu tür bir sisteminiz yoksa, nesne türünün ön ekini veya sonekini kullanmanın olmadığını söylemiştiniz .

Biz gibi ekleri kullanılmaz olduğunu not _table, _packageveya _view(yani tip nesnesinin). Örneğin, hem (3) hem de (4) PL / SQL paketleridir, ancak farklı bir sonek kullanırlar. Her ikisi de indeks olan (5) ve (6) için aynıdır. Bu yüzden sonek türden çok bir amacı temel alır .

(Büyük olasılıkla) gereksiz bilgileri ekler, bilişsel ek yüke yol açar ve bu nedenle de kaldırılmalıdır.

Bağlam , özellikle bilgisayar sistemlerinde harika bir şey. Bağlam dışı bir şeyin usersmasa, görünüm, saklı bir prosedür veya tamamen başka bir şey olup olmadığını söyleyemezsiniz . Eski (ya da sadece yanlış yazılmış) sistemler ve diller genellikle kodu okurken bağlamda çalışmayı zorlaştırır. Örneğin, Bash, ne söyleyemem function usersolmadan yapar , en azından fonksiyonun içeriğini okuma. Java'da Map<Uid,UserDetails> users()oldukça şeffaftır ve ayrıntılara kolayca bakabilirsiniz.

Bu argümanı SQL tablolarına alarak , tüketicilerin bir tablo mu yoksa görünüm mü olduğunu bilmek ne zaman faydalı olacaktır users? Başka bir deyişle, bir tblön ek, tüketicilere bilmedikleri ve bilmeleri gereken bir şey söyleyecek mi?İnşallah tüketicilerin büyük çoğunluğu DML ve DQL hakkında soru soracaktır. Onlar için sadece başka bir veri kaynağı olmalı ve bir görünüm mü yoksa bir tablo mu ayrıldığına, HDD’de veya SSD’de saklandığına ya da başka bir teknik detaya kadar alakalı olmalıdır. Elbette DBA’nın bazı nadir DDL / DCL sorgularını yürütmesi için bu detayları bilmesi gerekir, ancak şemaya nasıl gidileceğini ve tüm teknik detayların nasıl alınacağını bilen azınlık uğruna ad alanını kirletmek verimsiz görünüyor.

İlişkisel bir veritabanı yönetim sisteminin özelliklerinden biri, bilgilerin mantıksal sunumunu istemcilere fiziksel depodan ayırmasıdır. İlki, bir satır kümesindeki sütunlardır. Sonuncusu, depolama birimindeki dosyalar gibidir. Birini diğerine eşlemek DBMS'nin işidir. Hangi donanımın bilgi ihtiyacını desteklediğini yalnızca DBA veya sysadmin için endişelendiriyor. Tüketici, bu endişelerin farkında olmamalıdır.

Müşteri de bir satır setinin nasıl inşa edildiğinden endişe etmemelidir. Bir taban tablosu, görünüm veya işlev, bu açıdan aynıdır. Her biri basitçe müşterinin tükettiği bir dizi satır ve sütun üretir. Basit bir skaler bile tek satırlık, tek sütunluk bir tablo olarak kabul edilebilir. Satır / sütun modeli, müşteri ile sunucu arasındaki sözleşmedir.

Eski eserlerin isimlerini uygulama türlerine ekleyerek bu endişelerin ayrılması bozulur. İstemci şimdi sunucunun içindekilerin farkında ve buna bağlı. Sunucunun kodlamasındaki değişiklik istemcinin yeniden çalışmasını gerektirebilir.

Burada size katılıyorum ki bunun çok değerli bir adlandırma kuralı olmadığını söyleyen birçok cevap var. Diğer cevaplarla ikna olmamış insanlar için, diğer birçok cevapların ne dediğini göstermeye çalışacağım.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

Yukarıdaki ifadede, adlandırılmış bir şeyden üç sütun seçiyorum dbo.foo. Öneklendiricilerin temel şikayetlerinden biri dbo.foo, bir tablo mu yoksa görünüm mü olduğunu bilmemeleridir . Tabii ki bu soyutlamanın bakış açısının güçlü yönlerinden biri ama ben dalıyorum. Nesneyi bu şekilde önizlememiz gerektiğini söylüyorlar dbo.tblFoo. Şimdi nesnenin yukarıdaki sorguda bir tablo (muhtemelen) olduğunu görebilirler. Ancak, bu hedefin işlevsel eşdeğerini yazarsak, bunun gibi görünecektir.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

Ben, yorum yapanların etkili bir şekilde savundukları şey olmasına rağmen, yorumların daha az kullanışlı göründüğünden şüpheleniyorum. İşe yaramaz gürültüyü vurgulamak için bu meta veri yorumunda enjeksiyonlar daha karmaşık bir sorgu düşünün.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

Ekstra yorumlar bu sorgunun nedenini kolaylaştırıyor mu, yoksa sadece ekstra gürültü ekliyor mu? Bence onlar sadece ekstra gürültü eklemek ve sıfır değer eklemek. Anti-öneklerin söylemeye çalıştığı şey budur. Ayrıca, önekleri kullanmak aslında bu yorumlardan daha kötüdür çünkü bir yorum güncelleme maliyeti, veri modelinizin uyarlanması gerekiyorsa ön ekli bir tablonun adını güncellemekten çok daha düşüktür. Bu ön eklerin bir maliyeti olduğundan ve değerli bilgiler vermediklerinden kaçınılması gerekir.

Bazı kişilerin bahsettiği öneklerin bir başka avantajı, geliştirme ortamınızda bir tür gruplandırma veya düzen verebilmesidir. Büyük miktarda zaman düzenleme kodu harcadığımız için, bu bazıları için baştan çıkarıcı bir argüman olabilir. Ancak benim deneyimlerime göre modern geliştirme ortamları, kodunuzu gereksiz meta verilerle sınırlamayan ve esnekliğinizi sınırlamayan eşdeğer veya üstün seçenekler sunar.

Bu birçok kez ele alınmıştı, ancak muhtemelen en ünlüsü bir Amerikan SQL ve ilişkisel veritabanı uzmanı olan Joe Celko tarafından . Şahsen, çevrimiçi olarak (onur duyduğum gibi) rantlarından birinin alıcı ucunda bulundum ve bu öneklerden "yuvarlanan" veya daha doğrusu " skeuomorphism " olarak tanımlandığı hakkında konuşuyor .

Genel fikir, bu öneklerin uzun zaman öncesinden (muhtemelen nesne isimlerine göre 8 baytlık bir limit gibi) isimlendirme sınırlamaları nedeniyle kodlama uygulaması olduğu, programcı neslinin, sadece "olduğu gibi, hiçbir şekilde yararlı bir sebep olmadan," halloldu".

Şirketler, blogcular ve programcılar kendi kodlama stilleriyle bilgi aktarırlar ve bazı stiller diğerlerinden biraz daha "Frankenstein" olabilir. Bir şirketin bir "ev tarzı" olabilir ve programcı bu uygulamayı öğrenmek zorunda kalır.

Zaman geçtikçe işler, orijinal olarak kullanılmalarının nedeni artık kullanımdan kaldırılmış olsa bile, yapışıyor. "Tibbling" ilişkisel veritabanı yönetiminde bunun en iyi bilinen örneklerinden biridir.

Yuvarlamak için: herhangi bir değer katmaz, orada olduğundan başka bir sebep olmadan her tablonun adına tam olarak 4 bayt depolama alanı ekler. Modern SQL Server sistemlerine hiçbir şey sunmuyor, ancak orada olması daha iyi hissettiriyorsa, devam edin ve kullanın.

Benim önerim, bunu hemen yapmayı bırakman olur. Bu sizi ilerletmek konusunda rahatsız edici hale getiriyorsa , tablo adlarınızın sonuna "_tbl" ekleyin . Tabii ki daha önce belirtilen sebeplerden ötürü, bunu yapmaya da gerek yok. İlk başta bunu yapmanı söyleyen kişi sana kötü tavsiyeler verdi. "Kuruluşumuzun fena halde kurduğu sistem açısından bu mantıklı" tavsiyesi kötü olabilirdi, ancak bu durumda onu düzeltmek onun göreviydi. Yine de kötü tavsiyeler.

“Tablolarınızı tbl ile öneklendirmeyin” gerçekten bir sorun mu?

Sistem ile ilgili olarak? Hayır. Diğer insanlarla ilgili olarak? Olabilir. Lotsa nefreti üretebilirsin.

Şahsen tabloları ön eklemem ama görünümler, saklı yordamlar, işlevler vb. Diğer nesnelerde yapıyorum.

Söylemek zorundayım lütfen bunu yapmayı kes. Geçmişte olmuş, ancak bunu yapmaya devam ederek, yerel bir kongre olduğunu düşünerek ve devam etmeyi düşünerek çevrenize gelen yeni insanları teşvik ediyorsunuz. Ama sadece devam etmeyecekler, biraz farklı şekilde yapacaklar

Belirli bir öğe için bir db trol yaparken, ve ben nesne gezgini açacak ve sadece ona kalacağımı düşünecek tek kişi ben değilim, bunun alfabetik olduğunu biliyorsun. Bu, öneklerin suları çamurlamaya başlamasına ve tblname, tbl_name, tbname, t_name ve diğer binlerce varyasyona kadar, zaten bir masa olduğunu bildiğiniz masayı bulmak gerçekten zorlaşıyor

Aynı şekilde her şeyi vw_ veya sp_ önekleyerek, birileri gelir ve SPname, spname, s_p_name alırsınız. Tüm önekleri kaldırın, yazılım öğenin ne olduğunu bilir, gerçekten bilmeniz gerekiyorsa bunun yerine bir sonek kullanın. NameOfMyView_v, NameOfMyProc_sp. görsel olarak aramak çok daha kolay

Ancak, uzun süredir saklanan bir işlemden geçiyorsanız ve bir görünümün veya bir tablonun görünümünün ne olduğunu kolayca söyleyemiyorsanız ne olur? İyi şanslar, bunların yine de takma olmaları ve sonek kurtarmaya gelmese bile

Yaptığınız şeyi değiştirmekten korkmayın ve adlandırma kurallarının çoktan vurulduğu bir ortama girerseniz, kendi kurallarınızı uygulamaktan çekinmeyin ve işleri daha iyi bir şekilde değiştirmeye başlayın. Mevcut kaosu eşleştirerek daha az kafa karıştırıcı hale getirme şansı yok, sadece moreso yapmak mümkün değil

Eğer 'tbl' ön ekine sahip olmanın bir avantajını düşünmek zorundaysam, şu anki SSMS’de intellisense ile yazabiliyorum.

select * from tbl

ve sonra ihtiyacım olan tablo adını bulun (tam tablo adı hakkında hiçbir fikrim olmadığını varsayarak). Bu tek adımlı bir iş. Tabii ki, ek adımı kullanarak tablonun adını her zaman bulabiliriz, ancak şunu söyleyebilirim ki 'tbl' öneki, bu BİR adım çalışmasıdır ve bu yüzden her zaman bir öneki tercih etmem (mutlaka 'tbl' değil) kendi ödev projem.

Düzenleme : (Çok fazla oy kullandıktan sonra, hala sql sunucusundaki belirli bir nesne kategorisine belirli bir önek vermenin bazı avantajlarını işaret etmenin faydalı olacağını düşünüyorum). Hiç kimse saklı yordam / fonksiyonlar / görünümler için bir ön eke sahip olduğundan şikayet etmiyor gibi görünüyor, ancak bunu tablolarla yapmak konusunda her zaman bir tartışma var. (Bana göre, gerçek dünyada tablolara bir ön ek verip vermediğimizden daha az umrumda değil).

Sql server 2005 günlerinde hatırlıyorum, hangi tabloların hangi depolarda kullanıldığını bulmak için bir gereklilik vardı. (Evet, başka yollar olduğunu biliyorum, burada tartışma yok).

Kariyerim birçok "en iyi uygulama" makalesi / makalesi okumakla büyüyor, ancak farklı senaryolarda hemen hemen her "en iyi uygulama" için ya da başka bir şekilde yeterince istisna gördüm. Bu yüzden, her zaman kendime ve DBA’nın arkadaşlarına iş gereksinimlerine göre karar vermelerini, “en iyi uygulamanın” kesin bir yeri olduğunu söylerim, ancak yalnızca kendi çevremiz bağlamında ele alınabilir.

dbo.UserVs düşünün dbo.tUser. Şimdi bu tablonun kullanıldığı koddaki tüm yerleri bulmak istediğinizi düşünün. Hangi versiyon bunu daha kolay hale getirir (veya mümkün bile olur?) "Kullanıcı" kelimesi, yorumlarda değişken adları, vb. Gibi birçok yanlış pozitif olabilir.

Bu, diğer cevapların hiçbirinde görmediğim bir şey, ancak ben bir geliştirici-cum-DBA'yım, bu nedenle belki de başkaları, sorguların uygulamaya dahil edilebileceği eski kod üzerinde çalışmak zorunda kalmamış, hepsinin değil Sorgular, şema ile yapılan referansları tam olarak nitelendiriyor ve bunun gibi şeyler. (Herşey tam nitelikli olsa bile, sen bulmalıyız dbo.Userve [dbo].[User]ve dbo.[User]böyle devam eder). Veya "bağımlılık bilgilerinin" eskileştiği ve hatalı olduğu veritabanı sürümleri (örneğin, MS-SQL'in eski sürümleri)

Yani, böyle karışık Ben çalıştığım bazı projeler üzerinde, bir zorunlu tveya vbasitçe bir daha seçici arama terimi yapmak, (tbl_ saçma alır) öneki.

Daha sonraki projelerde, SQL Server Veri Araçları (merhaba, Tüm Referansları Bul) ve yalnızca bir ORM katmanı aracılığıyla veritabanına erişim gibi şeyler sayesinde, yardımcı program yoktur, çünkü tablonun tüm kullanımlarını bulmak önemsizdir (yeniden adlandırıldığı gibi!)

Her iki tarafın da avantajları ve dezavantajları vardır. Takip edecek sözleşmelere karar vermek sadece ekibinizin veya şirketinizin liderliğine kalmış.

Birincisi, tblsözleşmeyi kullanıyoruz. Asıl sebep, senaryolarda ne yapmamız ve yapmamamız gerektiğini bilmemiz. Şemayı ezbere bilmeden çeşitli projeler ve atlayan insanlar var. Tablolarımız mantıksal adlara sahiptir, bu nedenle komut dosyası yazarken yolunuzu bulmak kolaydır. Bunu yaparken, bir masa bulduğumuzda, derhal (IntelliSense aracılığıyla) bir masa olduğunu biliyoruz. Öneki eklemenin fazla içerik eklemediğini söyleyebiliriz. Ancak, kaldırılması bağlam olmadığı anlamına gelir.

Öneki kullanmamanın tek gerçek avantajı değiştirilebilirliktir. Ancak, bunun potansiyel olarak tehlikeli bir durum olduğunu iddia ediyorum. Elbette, senaryolarınız ve sorgularınız bozulmayacak, ancak belki de bu gerçeğe çok fazla güvenmeye başladınız, bazı şeyler ise sadece görüşlerle çalışmaz ya da tavsiye edilmez.

Sonunda, gerçekten sadece ekibinizin tercih ettiği şeylere ve kod / senaryoları nasıl yazdığına bağlıyor.

Tablo adlarını "tbl" ile öneklemek için bir neden kullanırdım. Bir veritabanı nesnesi listesine bakıyorsanız, bu sorguyu çalıştırabilirsiniz:

select * from sysobjects

Yalnızca tablo almak istiyorsanız, bunu yapabilirsiniz:

select * from sysobjects where type = 'U'

Bunu kim hatırlayabilir? Tablo adlarınızın tümü "tbl" ile başlıyorsa, bu sütunu tür sütununun değerlerini ezberlemenizi gerektirmeyen bu sorguyu kullanabilirsiniz:

select * from sysobjects where name like 'tbl%'

SQL Server 2014’u etiketlediğinizden beri, bu sizin için geçerli değildir, çünkü SQL Server 2005'ten itibaren bunu yapabilirsiniz:

select * from sys.tables

Tablo adlarını öneklemek için başka bir neden düşünemiyorum.