it-swarm.asia

Sütun adlarının önekinin eklenmesi neden kötü uygulama olarak kabul edilir?

göre bir popüler SO post tablo adlarının önek için kötü bir uygulama olarak kabul edilir. Benim şirket her sütun bir tablo adının önüne gelir.Bu benim için zor.Neden emin değilim, ama bu adlandırma aslında şirket standardı. Adlandırma kuralına dayanamıyorum, ama var muhakeme yedeklemek için hiçbir belge.

Tek bildiğim şu ki AdventureWorks'ü okumak çok daha basit. İçinde bu firmamız DB bir tablo, Kişi göreceksiniz ve sütun adı olabilir:

Person_First_Name
hatta belki
Person_Person_First_Name (bana neden 2x kişiyi gördüğünüzü sorma)

Sütun adlarını önceden düzeltmek neden kötü bir uygulama olarak kabul edilir? Alt çizgiler SQL'de de kötü olarak kabul edilir mi?


27
P.Brian.Mackey

Alt çizgiler kötülük değildir sadece yazmak daha zordur. Kötü olan, varolan tüm nesneleri düzeltmeden standartların orta akışını değiştirmektir. Artık personId, Person_id, vb. Var ve hangi tablonun alt çizgi kullandığını ya da kullanmadığını hatırlayamıyorum. Adlandırmadaki tutarlılık (adları kişisel olarak beğenmeseniz bile) kodlamayı kolaylaştırır.

Şahsen bir sütunda tablename kullanmak için ihtiyaç duyduğum tek yer ID sütununda (kapsamlı raporlama sorguları yapan herkes size söyleyebileceği gibi sadece ID kullanımı veritabanı tasarımında bir antipattern olduğunu. Her rapor yazdığınızda sorgunuzda 12 sütun bulunur.) Bu aynı zamanda diğer tablolardaki FK'lerin aynı ada sahip olduklarını hemen bilmelerini kolaylaştırır.

Ancak, olgun bir veritabanında, mevcut bir standardı değiştirmeye değer olduğundan daha fazla iştir. Sadece standart olduğunu kabul edin ve devam edin, önce düzeltilmesi gereken çok daha kritik şeyler var.

45
HLGEM

Sütun adı önekinin bağımsız değişkeni, birden çok tabloya katılırken VE sorgu yaratıcısı takma ad kullanmadığında "çarpışmaları" engellemektir.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Her iki sorgu da, hangi varlığa ait olduğunu "söylemeden" iki "ad" sütununa (ad_1, ad_2) sahip olacaktır. Ve oluşturulan sütun adlarından asla emin olamazsınız (ad_2 veya ad_3 veya ... olacak). Tablo adı önekini kullanırsanız sütun adları person_name, company_name olur, böylece ait olduğu varlıkların her adını bilirsiniz, ayrıca sütun adlarının kalacağını da bilirsiniz sabit (bunları Java) içinde alıyorsanız).

Takma ad kullanırsanız her iki argüman da göz ardı edilebilir, ancak şirketlerde uygulanan kodlama kurallarının çoğunun iyi uygulamaları takip etmeyen birçok (genç) programcının bir sonucu olduğunu düşünüyorum. Bu durumda, örneğin, bir SELECT deyiminde joker karakter kullanmak ad öneki olmadan sorunlara neden olabilir.

Tablo ve sütun adlarındaki alt çizgilere gelince, ayırıcı olarak adlarda yalnızca küçük harf artı alt çizgi kullandığım için yaygın olarak kullanıyorum. Yalnızca küçük harf kullanmak, tanımlayıcıları SQL anahtar sözcüklerinden ayırmaya yardımcı olur (tüm büyük harfleri yazarım):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'
18
Nicolae Albu

Bu tür önekleri sütun adlarına eklemek bir tablonun gelişmesini zorlaştıracaktır. Örnek olarak: sonunda tablo adını değiştirmek istediğinizi/ihtiyacınız olduğunu fark ederseniz, tüm tablo yapınızı (yani, yalnızca tablonun adını değil, tüm sütunlarının adını) değiştirmeniz gerekecektir. Bu da tablonun dizinlerini ve sorgulayan istemcilerin kodunu güncellemeyi zorlaştırır.

9
Sergio

Çok sık karşılaşılan sık karşılaşılan (== --- ==) ortak sütun adları (normalde yalnızca kimlik, bazen Ad) için akıllıca kullanılırsa (bağlantınızdaki Patrick Karcher'ın cevabına göre) istisnalar vardır .

Başka bir en iyi uygulama, sorgularınızdaki sütunları ve nesneleri her zaman nitelendirmektir. Böylece sütun önekleri tartışmaya başlar ve kodunuzu karmaşık hale getirir.

Bunları karşılaştırın: hangisi göze en kolay?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person
5
gbn

Genel olarak, her yerde her yerde standartlar yok gibi görünüyor. Bağlantı kurduğunuz sorunun, tamamen farklı sözleşmelerle yüksek oy alan birkaç yanıtı vardır. Tabii ki, herkes kendi standartlarını savunacak ve bir projede tutarlı sözleşmeleri tutmak çok daha önemlidir.

Bununla birlikte, sütun adlarının önekinin aşılması aşırı gibi görünüyor. Hangi tabloyla çalıştığınızı zaten biliyorsunuz ve aynı ada sahip farklı tablolardan iki sütun içeren bir durum, tablo veya sütun takma adları kullanılarak kolayca çözülebilir.

3
Dan Simon

Belirsizliği önlemek istiyorsanız, TSQL'de TableName.FieldName formundaki alanlara başvurabilirsiniz; böylece alan adlarına tablo adları eklemek gerçekte okunabilirlikten kaçınır ve bu da TableName.TableName_FieldName veya benzeri olur. Bence alt çizgi kullanmak ya da istememek daha kişisel bir seçimdir. CamelCase tercih ve ben bir ek veya benzeri eklemek istediğinizde _ kullanın TableName_Temp, ama bu sadece benim.

2
Ben Robinson

Bir zamanlar sütunları öneklemek için kısa kodlar kullanmaya karar verdiğimiz bir sistem üzerinde çalıştım. PK alanları önek olarak "tam tablo adı" nı, diğer tüm sütunlar ise önekleri olarak tutarlı bir şekilde 2-4 karakter kullanıyordu. Her sütun, soneki olarak bir veri alanı da kullandı. Tutarlı bir şekilde yapılırsa, çok güzel ve temiz olabilir. Bir tür veya başka bir adlandırma standardının özensiz kodlamayı içermesi saçmalıktır. Tutarlı bir standardın varlığı önemlidir. Açık bir standart olmadığı ve veri yapılarında bir sorun olabileceğini bana her şeyden daha fazla göstereceği için tutarsız olan birkaç veritabanı gördüm. Bir veritabanının tasarımcısı nesnelere ve çocuklarına tutarlı bir şekilde isim veremiyorsa, neden bu altta yatan veri modeli, ilişkiler, kısıtlamalar, bütünlük vb. Hakkında tutarlı veya düşünceli bir şey olduğuna inanmamı sağlar?

2
Tom

Önekleme kötü bir uygulamadır çünkü tasarlanması problemi önler. Belirttiğiniz gibi, ön ekli sütunları okumak çok zor. İki tabloyu birleştirdiğiniz bir sorguda yinelenen sütun adlarıyla karşılaşırsanız, tabloyu çözebilir veya sürekli olarak belirli tablolara katıldığınızda bunu sizin için yapan bir görünüm, saklı yordam veya tablo kullanıcı tanımlı bir işlevdir.

Tablo adında altı çizili olarak kullanmak, bu dini bir argüman. Sonunda görünürlüğü arttırır ve işleri kolaylaştırırsa. Genellikle sütun veya tablo adında boşluk veya tablo olmazdı. Ancak, yalnızca bir raporlama paketi tarafından kullanılan veya bir CSV dosyasına aktarılan tablolar veya görünümler için bir istisna yapabilirim.

1
Justin Dearing

Birçok veritabanının sütun adındaki (yani Oracle) karakter sayısı konusunda katı sınırları vardır.

Uzun sütun adlarına izin veren bir veritabanıyla çalışıyorsanız, ancak daha sonra bu yapıyı başka bir veritabanı sistemine taşımak istediğinize karar verirseniz, önekler sütun adlarınızın geçersiz olma olasılığını artırır.

Şu anda SQL Server ile çalışmanıza rağmen, kimse geleceği tahmin edemez ve yazılımınızın gelecekte birden çok veritabanında çalışması gerekebilir.

1
Britt Wescott

Bir veri sözlüğü (veya "kayıt defteri") yazmayı düşünün. Bununla, modelinizdeki tüm veri öğelerini içeren bir belgeyi kastediyorum: ad, açıklama vb. Modelin uygulanmasından bağımsız olmalıdır. tablo adlarından bahsetmemelidir. 'Kimlik', 'Tür' ve 'Kod' gibi adları nasıl belirsizleştirirsiniz?

Bir yaklaşım, uluslararası standart ISO/IEC 11179 yönergelerine uymaktır - sonuçta, tekerleği neden yeniden icat edesiniz? Temel yapı:

[Object] [Qualifier] Property RepresentationTerm

öğeler arasında sınırlayıcılar ile: SQL sütun adları ve alt çizgi boşlukları ile Nice oynamıyor görsel olarak iyi çalışır.

Kuruluşunuzdaki birisinin Person_Person_First_Name Gibi öğe adları bulduğunda bu yönergelere uymaya çalıştığını hissediyorum.

Göstermek istediğim örnek İngiltere Ulus Sağlık Hizmeti (NHS) veri sözlüğüdür .

Bu yüzden adlandırma kuralının çok kötü seslerle çalışması gerektiğini düşünmüyorum.

Uygulamada ör. SQL'de, bazı kişiler tablo adı bağlam sağladığında Object, Qualifier ve Property alt öğelerini atlamayı sever. person_first_name, Person tablosunda vb. first_name Olur. Ancak, bir veri öğesinin yalnızca fiziksel modeldeki konumu nedeniyle adını değiştirmemesi gereken temel kural gibi görünüyor iyiydi. Bu kurala uymanın iyi bir fikir olmadığını düşünen herkese, kullandıkları tüm ad varyasyonlarını belgeleme görevi verilmelidir :)

ISO 11179'un güzel bir özetini Joe Celko'nun Programlama Stili , sütun adlarında sınırlayıcı olarak alt çizgileri tercih etmek için kanıtlar da bulacaksınız.

0
onedaywhen

Bazıları, verilerin hangi tablodan geldiğini bilmek için kodda daha kolay bulmaktadır, ancak, nesne yönelimli bir sistemden bahsediyorsanız, ismin bağlamını kullanmanız gerekir, bu durumda tablo adı.

Şahsen, tablo adı öneki, geliştiricilerin çok yetenekli olmadığının bir göstergesi ve daha derine indiğinizde diğer birçok kötü kodlama kurallarını bulacaksınız ve eğer uygulamanın çok fazla tabloya sahip olduğunu tahmin edersem, buggy, vb.

0
Bill Leeper