Veritabanı tablolarında kimlik sütunlarının adlandırılması

Veritabanı tablolarındaki kimlik sütunlarının adlandırılmasıyla ilgili insanların görüşlerini merak ediyordum.

Bir kimlik sütununun birincil anahtarına sahip Faturalar adında bir tablom varsa, bu sütunu InvoiceID olarak adlandırırım, böylece diğer tablolarla çakışmaz ve ne olduğu açıktır.

İşyerinde güncel olduğum yerde, tüm kimlik sütunlarını ID olarak adlandırdılar.

Böylece şunları yapacaklardı:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Şimdi, burada birkaç sorun görüyorum:
1. Seçili sütunların takma
adlarını kullanmanız gerekir 2. ID = InvoiceID beynime uymuyor
3. Tabloları değiştirmediyseniz ve InvoiceID'ye başvurduysanız, hangi tablonun olduğu açıktır açık?

Konuyla ilgili diğer insanların düşünceleri nelerdir?

ID bir SQL Antipattern'dir. Bkz. Http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Kimlik olarak kimliği olan birçok tablonuz varsa, raporlamayı çok daha zor hale getiriyorsunuz. Anlamı belirsizleştirir ve karmaşık sorguları okumayı zorlaştırır ve ayrıca raporun kendisini ayırt etmek için takma adlar kullanmanızı gerektirir.

Dahası, eğer biri mevcut olduğu bir veritabanında doğal bir birleşimi kullanacak kadar aptalsa, yanlış kayıtlara katılacaksınız.

Bazı dbs'lerin izin verdiği KULLANIM sözdizimini kullanmak istiyorsanız, kimlik kullanıyorsanız kullanamazsınız.

Kimlik kullanırsanız, birleştirme sözdizimini kopyalıyorsanız (bana kimsenin bunu yapmadığını söyleme!) Ve birleştirme koşulundaki takma adı değiştirmeyi unutursanız, kolayca hatalı bir birleştirme ile sonlandırabilirsiniz.

Yani şimdi sahipsin

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

demek istediğin zaman

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Kimlik alanı olarak tablenameID kullanırsanız, bu tür kazara oluşan bir hatanın olması çok daha az olasıdır ve bulunması çok daha kolaydır.

Kimlik sütunu için ID'yi TableName + ID'ye ve ardından bir yabancı anahtar için TableName + ID'ye tercih ettim. Bu şekilde, tüm tablolar kimlik alanı için aynı ada sahip olur ve gereksiz bir açıklama olmaz. Bu bana daha basit geliyor çünkü tüm tablolar aynı birincil anahtar alan adına sahip.

Tabloları birleştirmek ve hangi kimlik alanının hangi tabloya ait olduğunu bilmemekle ilgili görüşüme göre sorgu bu durumu ele alacak şekilde yazılmalıdır. Çalıştığım yerde, bir ifadede kullandığımız alanları her zaman tablo / tablo takma adıyla tercih ederiz.

Son zamanlarda benim şirketimde bu şey hakkında bir inek kavgası oldu. LINQ'nun ortaya çıkışı, fazlalık tablename + ID modelini gözlerimde daha da aptalca yaptı. Bence çoğu mantıklı insan, SQL'inizi FK'leri ayırt etmek için tablo adlarını belirtmek zorunda kalacak şekilde elle yazıyorsanız, bu sadece yazma konusunda bir tasarruf değil, aynı zamanda SQL'inize sadece kullanmak için netlik kattığını söyleyecektir. Kimin PK ve hangisinin FK olduğunu açıkça görebileceğiniz kimlik .

Örneğin

ÇALIŞANLARDAN e LEFT JOIN Müşterilere c ON e.ID = c. EmployeeID

bana sadece ikisinin bağlantılı olduğunu değil, hangisinin PK ve hangisinin FK olduğunu söylüyor . Oysa eski tarzda, iyi isimlendirildiklerine bakmak ya da umut etmek zorunda kalıyorsunuz.

Biz kullanmak InvoiceIDdeğil ID. Sorguları daha okunaklı hale getirir - IDyalnız gördüğünüzde herhangi bir şey ifade edebilir, özellikle de tabloyu takma ad verdiğinizde i.

Keven ve buradaki diğer birkaç kişiyle, bir tablonun PK'sinin sadece Id olması ve yabancı anahtarların OtherTable + Id'yi listelemesi konusunda hemfikirim.

Bununla birlikte, son zamanlarda bu tartışmaya daha fazla ağırlık veren bir neden eklemek istiyorum.

Şu anki pozisyonumda, POCO üretimini kullanarak varlık çerçevesini kullanıyoruz. Id'nin standart adlandırma kuralını kullanarak, PK, bir temel poco sınıfının doğrulama ile ve bir dizi ortak sütun ismini paylaşan tablolar için kalıtımına izin verir. Tablename + Id'nin bu tabloların her biri için PK olarak kullanılması, bunlar için bir temel sınıf kullanma yeteneğini ortadan kaldırır.

Düşünmek için biraz yiyecek.

Tercihim ayrıca birincil anahtar için ID ve yabancı anahtar için TableNameID'dir. Ayrıca, girişin kullanıcı tarafından okunabilir tanımlayıcısını (yani adı :-)) tuttuğum çoğu tabloda bir sütun "adı" olmasını da seviyorum. Bu yapı uygulamanın kendisinde büyük esneklik sunuyor, aynı şekilde tabloları toplu olarak işleyebiliyorum. Bu çok güçlü bir şey. Genellikle veritabanının üzerine bir OO yazılımı oluşturulur, ancak OO araç seti, veritabanının kendisi buna izin vermediği için uygulanamaz. Sütun kimliği ve adı hala çok iyi değil, ancak bu bir adım.

Faturalardan i.ID, il.ID'yi seçin i.ID = il.InvoiceID'de InvoiceLines'a Ayrıl.

Bunu neden yapamıyorum?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

Bence bu çok okunabilir ve basit. Değişkenleri i ve il olarak adlandırmak genel olarak kötü bir seçimdir.

Bu gerçekten önemli değil, muhtemelen tüm adlandırma kurallarında simalar problemleriyle karşılaşacaksınız.

Ancak, her sorgu yazdığınızda tablo tanımlarına bakmak zorunda kalmamanız için tutarlı olmak önemlidir.

Sadece "ID" kullanan bir yerde çalışmaya başladım (çekirdek tablolarda, yabancı anahtarlarda TableNameID tarafından başvurulan) ve zaten doğrudan bunun neden olduğu İKİ üretim problemi buldum.

Bir durumda sorgu "... burada ID (DiğerTablodan KİMLİĞİ SEÇ ..." yerine "... (DiğerTablodan KİMLİĞİ SEÇ ..."

Dürüst olmak gerekirse, yanlış ifadenin "... içinde TransID (OtherTable'dan OtherTableID'yi SEÇİN ..." yazdığı yerde tam ve tutarlı isimler kullanıldığında fark edilmesinin daha kolay olmayacağını söyleyebilir mi? yani.

Diğer sorun kodu yeniden düzenlerken ortaya çıkar. Daha önce sorgu bir çekirdek tablodan çıkarken geçici bir tablo kullanırsanız, eski kod "... dbo.MyFunction (t.ID) ..." okur ve bu değiştirilmez ancak "t" artık bir Çekirdek tablo yerine geçici tablo, bir hata bile almazsınız - sadece hatalı sonuçlar.

Gereksiz hatalar üretmek bir amaçsa (belki bazı insanların yeterince işi yoksa?), O zaman bu tür bir adlandırma kuralı harikadır. Aksi takdirde tutarlı adlandırma, gidilecek yoldur.

Basitlik uğruna çoğu kişi sütunu tablo kimliğinde adlandırır. Başka bir tabloda yabancı anahtar referansı varsa, o zaman açıklıkla buna InvoiceID (örneğinizi kullanmak için) adını verirler, yine de tabloyu takma ad olursunuz, böylece açık fatura kimliği hala faturadan daha basittir.

Ben şahsen (yukarıda belirtildiği gibi) tercih Table.ID için PK ve tableId için FK . Hatta (lütfen beni vurmayın) Microsoft Access bunu önerir.

ANCAK, ben AYRICA içerdikleri tüm sütun adını bağlamak eğilimindedir, çünkü bazı üreten araçları PK için tableId yanlısı olduğu gerçeğini biliyorum 'kimliği' sözcüğü, içinde kimlik DAHİL !!!

Sorgu tasarımcısı bile bunu Microsoft SQL Server'da yapar (ve oluşturduğunuz her sorgu için, sütun kimliğindeki tüm tablolarda yeni oluşturulan tüm gereksiz ilişkileri koparırsınız)

BUNUNLA DAHİLİ OCD'm ondan nefret etse de, TableID geleneğini uyguluyorum . En bir veri denir olduğunu hatırlayalım BAZ o gelmek umarım çok çok birçok uygulama için temel olacak şekilde,. Ve tüm teknolojiler, net bir açıklama ile normalleştirilmiş bir Şemadan yararlanmalıdır.

İnsanlar TableName, TableDescription vb. Kullanmaya başladığında çizgimi çizdiğimi söylemeye gerek yok. Bana göre, sözleşmeler şunları yapmalı:

• Tablo adı: Çoğullaştırılmış. Örn. Çalışanlar

• Tablo diğer adı: Tam tablo Adı, tekilleştirilmiş. Örn.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well
  

[Güncelleme]

Ayrıca, bu ileti dizisinde "ilişki türü" veya rol nedeniyle yinelenen sütunlar hakkında bazı geçerli gönderiler var. Örneğin, bir Mağazada bir EmployeeID varsa , bu bana çömelmeyi söyler. Bu yüzden bazen Store.EmployeeID_Manager gibi bir şey yapıyorum . Elbette biraz daha büyük ama en azından insanlar tablo ManagerID'yi veya EmployeeID'nin orada yaptıklarını bulmaya çalışırken çıldırmayacaklar . Sorgulama NEREDE olduğunda, bunu şu şekilde basitleştirmek isterim: Mağazadan Yönetici Kimliği olarak Çalışan Kimliği_Yöneticisini SEÇİN

Buna resmi bir veri sözlüğü perspektifinden gelirsek, veri unsurunu adlandırırım invoice_ID. Genel olarak, bir veri öğesi adı veri sözlüğünde benzersiz olacaktır ve ideal olarak baştan sona aynı ada sahip olacaktır, ancak bazen bağlama göre ek niteleyici terimler gerekebilir, örneğin adı verilen veri öğesi employee_IDkuruluş şemasında iki kez kullanılabilir ve bu nedenle şu şekilde nitelendirilebilir: supervisor_employee_IDve subordinate_employee_IDsırasıyla.

Açıkçası, adlandırma kuralları özneldir ve bir stil meselesidir. ISO / IEC 11179 yönergelerinin yararlı bir başlangıç ​​noktası olduğunu düşünüyorum.

DBMS için, tabloları varlık koleksiyonları olarak görüyorum (sadece bir satır içerenler hariç, örneğin cofig tablosu, sabitler tablosu, vb.), Örneğin employee_IDanahtarın my olduğu tablo adlandırılacaktır Personnel. Yani TableNameIDkongre benim için hemen işe yaramıyor.

TableName.ID=PK TableNameID=FKBüyük veri modellerinde kullanılan stili gördüm ve biraz kafa karıştırıcı bulduğumu söylemeliyim: Bir tanımlayıcının adının her yerde aynı olmasını tercih ederim, yani adı hangi tabloda göründüğüne göre değiştirmez. Dikkat edilmesi gereken bir şey var. Yabancı anahtarlarda doğal ve bileşik anahtarlardan kaçınırken her tabloya bir IDENTITY(otomatik artış) sütun ekleyen mağazalarda söz konusu stil kullanılıyor gibi görünüyor . Bu dükkanlar, resmi veri sözlüklerine sahip olmama veya veri modellerinden oluşturmama eğilimindedir. Yine, bu sadece bir tarz meselesi ve şahsen katılmadığım bir soru. Yani sonuçta bana göre değil.

Bütün bunlar, ben tablonun adı adında elemanı bunu yaparken örneğin bir bağlam sağlar bazen sütun adından eleme bırakarak için bir durumda görebilirsiniz employee_last_namebasitçe hale gelebilir last_nameiçinde Personnelmasaya. Burada mantık alanı 'insanların soyadları' ve daha büyük olasılıkla edilecek olmasıdır UNIONile ed last_namesütunlar dan ziyade bir yabancı anahtar olarak kullanılacak başka tablolarla içinde , sadece fikrimi değiştirebilir ... sonra yine başka bir masaya, ama bazen asla söyleyemezsin. Mesele şu: veri modelleme kısmen sanat, kısmen bilim.

Tutarlı olduğunuz sürece "kimlik" için her şeyi kullanabileceğinizi düşünüyorum. Tablo adının dahil edilmesi önemlidir. İsimlendirme kurallarını ve standartlarını uygulamak için Erwin gibi bir modelleme aracı kullanmanızı öneririm, böylece sorgu yazarken tablolar arasında var olabilecek ilişkileri anlamak kolay olur.

İlk ifadeden kastım, ID yerine 'recno' gibi başka bir şey kullanabilirsiniz. Bu durumda, bu tablo bir PK invoice_recno'ya sahip olur ve bu böyle devam eder.

Şerefe, Ben

Oyum, tablo kimliği için InvoiceID içindir. Yabancı anahtar olarak kullanıldığında da aynı adlandırma kuralını kullanıyorum ve sorgularda akıllı takma adlar kullanıyorum.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Elbette, diğer bazı örneklerden daha uzun. Ama gülümse. Bu gelecek nesiller içindir ve bir gün, bazı zavallı genç kodlayıcılar başyapıtınızı değiştirmek zorunda kalacak. Bu örnekte belirsizlik yoktur ve sorguya ek tablolar eklendikçe, ayrıntı için minnettar olacaksınız.

Veritabanındaki sütun adı için "InvoiceID" kullanırım.

Alanları LINQ aracılığıyla adsız bir yapıya kopyalarsam, yapıdaki tek kimlik ise, orada "ID" olarak adlandırabilirim.

Sütun yabancı bir anahtarda KULLANILMAYACAK, böylece yalnızca düzenleme düzenleme veya silme için bir satırı benzersiz şekilde tanımlamak için kullanılacaksa, ona "PK" adını vereceğim.

Her anahtara benzersiz bir ad verirseniz, örneğin "invoices.id" yerine "invoices.invoice_id", "doğal birleştirme" ve "kullanma" operatörlerini endişelenmeden kullanabilirsiniz. Örneğin

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

onun yerine

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL, onu daha ayrıntılı hale getirmeden yeterince ayrıntılıdır.

İşlerin kendim için tutarlı olmasını sağlamak için yaptığım şey (bir tablonun kimlik olarak kullanılan tek sütun birincil anahtarına sahip olduğu durumlarda) tablonun birincil anahtarını adlandırmaktır Table_pk. Bu tablolara birincil anahtar işaret eden bir yabancı anahtarımın olduğu her yerde, sütunu çağırırım PrimaryKeyTable_fk. Bu şekilde, Customer_pkMüşteri tablomda ve Customer_fkSipariş tablomda bir varsa, Sipariş tablosunun Müşteri tablosundaki bir girişe atıfta bulunduğunu biliyorum.

Bana göre, bu özellikle daha kolay okuduğunu düşündüğüm katılımlar için mantıklı.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, yeni standardımız (her yeni projede değişen, uh, yani "gelişir" demek istiyorum):

• Küçük harfli veritabanı alan adları
• Büyük harfli tablo adları
• Alan adındaki kelimeleri ayırmak için alt çizgi kullanın - bunları kodda Pascal büyük harf durumuna dönüştürün.
• pk_ önek, birincil anahtar anlamına gelir
• _id sonek bir tam sayı, otomatik artış kimliği anlamına gelir
• fk_ önek yabancı anahtar anlamına gelir (son ek gerekmez)
• _VW görünümler için son ek
• is_ boole'lar için önek

Yani, bir tablo adında İSİMLERİ alanlara sahip olabilir pk_name_id, first_name, last_name, is_alive,ve fk_companyadlı bir görünüm LIVING_CUSTOMERS_VWgibi tanımlanmış:

Ad, soyadı SEÇİN
CONTACT.NAMES'DEN
NEREDE (is_alive = 'Doğru')

Başkalarının da söylediği gibi, tutarlı olduğu ve anlamlarınızı gereksiz yere gizlemediği sürece hemen hemen her şema işe yarayacaktır.

Verdiğiniz sebeplerden ötürü, kimlik alan adına tablo adını eklemeye kesinlikle katılıyorum. Genel olarak, tablo adını dahil edeceğim tek alan budur.

Sade kimlik isminden nefret ediyorum. Her zaman invoice_id veya bunun bir varyasyonunu kullanmayı kesinlikle tercih ediyorum. İhtiyaç duyduğumda kimlik için hangi tablonun yetkili tablo olduğunu her zaman bilirim, ancak bu kafamı karıştırıyor

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

En kötüsü, bahsettiğiniz karışım, tamamen kafa karıştırıcı. En çok kullanılan kimliklerden biri dışında neredeyse her zaman foo_id olan bir veritabanıyla çalışmak zorunda kaldım. Bu tam bir cehennemdi.

DomainName'i tercih ediyorum || 'İD'. (yani EtkiAlanıAdı + Kimlik)

EtkiAlanıAdı genellikle, ancak her zaman değil, TableName ile aynıdır.

Kimliğin tek başına sorunu, yukarı doğru ölçeklenmemesidir. Her biri ID adlı bir ilk sütuna sahip yaklaşık 200 tablonuz olduğunda, veriler birbirine benzemeye başlar. Kimliği her zaman tablo adıyla nitelendirirseniz, bu biraz yardımcı olur, ancak o kadar da değil.

EtkiAlanıAdı ve Kimliği, birincil anahtarların yanı sıra yabancı anahtarları da adlandırmak için kullanılabilir. Foriegn anahtarlar, referans verdikleri sütundan sonra adlandırıldığında, bu anımsatıcı yardımcı olabilir. Resmi olarak, bir yabancı anahtarın adını referans verdiği anahtara bağlamak gerekli değildir, çünkü referans bütünlüğü kısıtlaması referansı oluşturacaktır. Ancak sorguları ve güncellemeleri okumak söz konusu olduğunda son derece kullanışlıdır.

Bazen EtkiAlanıAdı || Aynı tabloda aynı ada sahip iki sütun olacağından "kimlik" kullanılamaz. Örnek: Employees.EmployeeID ve Employees.SupervisorID. Bu durumlarda, RolAdı || Örnekte olduğu gibi 'ID'.

Son olarak, mümkün olduğunda yapay anahtarlar yerine doğal anahtarlar kullanıyorum. Doğal anahtarların kullanılamadığı veya güvenilmez olduğu durumlar vardır, ancak doğal anahtarın doğru seçim olduğu birçok durum vardır. Bu durumlarda, doğal anahtarın doğal olarak sahip olacağı adı almasına izin verdim. Bu isimde genellikle 'ID' harfleri bile bulunmaz. Örnek: OrderNo, No, "Number" için bir kısaltmadır.

Her tablo için bir ağaç harfi kısaltması seçiyorum (örneğin Çalışanlar => Emp)

Bu şekilde sayısal bir otomatik sayı birincil anahtarı nkEmp olur .

Kısa, tüm veritabanında benzersiz ve özelliklerini bir bakışta tam olarak biliyorum.

SQL'de ve kullandığım tüm dillerde (çoğunlukla C #, Javascript, VB6) aynı isimleri saklıyorum.

İyi düşünülmüş bir tablo ve sütun adlandırma sistemi için Interakt sitesinin adlandırma kurallarına bakın. Yöntem, her tablo için ( _prdbir ürün tablosu veya _ctgbir kategori tablosu için) bir sonek kullanır ve bunu belirli bir tablodaki her bir sütuna ekler. Dolayısıyla, ürünler tablosunun kimlik sütunu id_prdveritabanında benzersiz olacaktır ve bu nedenle benzersizdir.

Yabancı anahtarları anlamaya yardımcı olmak için bir adım daha ileri giderler: Kategori tablosuna atıfta bulunan ürün tablosundaki yabancı anahtar, idctg_prdhangi tabloya ( _prdson ek) ve hangi tabloya (kategori) atıfta bulunduğunun açıkça görülebilmesi için olacaktır. .

Avantajları, farklı tablolardaki kimlik sütunlarında belirsizlik olmaması ve bir sorgunun sütun adlarıyla hangi sütunlara atıfta bulunduğunu bir bakışta anlayabilmenizdir.

Aşağıdaki adlandırma kuralını kullanabilirsiniz. Kusurları var ama sizin özel sorunlarınızı çözüyor.

1. Tablo adları için kısa (3-4 karakter) takma adlar kullanın, örn. Invoice - inv, InvoiceLines -invl
2. Tablodaki sütunlara bu takma adları kullanarak ad verin, ör inv_id.invl_id
3. Referans sütunlar invl_inv_idiçin isimler için kullanın .

bu şekilde söyleyebilirsin

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id