Birincil anahtar / yabancı Anahtar adlandırma kuralı [kapalı]

Geliştirme grubumuzda, Birincil ve Yabancı Anahtarlar için adlandırma kuralıyla ilgili şiddetli bir tartışmamız var. Grubumuzda temelde iki düşünce okulu var:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

veya

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Tablonun adını sütunların hiçbirinde çoğaltmamayı tercih ederim (Bu nedenle yukarıdaki 1. seçeneği tercih ederim). Kavramsal olarak, özellik adlarında nesnenin adını kullanmadığınız diğer dillerde önerilen uygulamaların çoğu ile tutarlıdır. Yabancı anahtarı adlandırmanın EmployeeID(veya Employee_IDdaha iyi olabileceğini) okuyucuya bunun IDTablonun sütunu olduğunu söylediğini düşünüyorum Employee.

Bazıları seçenek 2'yi tercih eder, burada birincil anahtarı tablo adı ile ön ek olarak adlandırırsınız, böylece sütun adı veritabanı genelinde aynı olur. Bu noktayı görüyorum, ancak artık birincil anahtarı görsel olarak yabancı anahtardan ayıramazsınız.

Ayrıca, tablo adının sütun adında bulunmasının gereksiz olduğunu düşünüyorum, çünkü tabloyu bir varlık ve bir sütunu o varlığın bir özelliği veya özniteliği olarak düşünürseniz, onu Employeedeğil EmployeeIDbir çalışanın niteliği. Bir onun ya benim astı sormuyorsun PersonAgeveya PersonGenderolduğunu. Ona Yaşının kaç olduğunu soruyorum.

Dediğim gibi, bu şiddetli bir tartışma ve biz bu konuda sürekli devam ediyoruz. Yeni bakış açıları edinmekle ilgileniyorum.

Gerçekten önemli değil. 1. seçim ile 2. seçenek arasında gerçek bir farkın olduğu bir sistemle asla karşılaşmadım.

Jeff Atwood'un bir süre önce bu konuda harika bir makalesi vardı. Temelde insanlar yanlış olduğu kanıtlanamayacak konuları en öfkeyle tartışır ve tartışırlar. Ya da farklı bir açıdan, yalnızca haydut tarzı dayanıklılığa dayalı son adam-ayakta duran argümanlarla kazanılabilecek konular.

Birini seçin ve kodunuzu gerçekten etkileyen konulara odaklanmalarını söyleyin.

DÜZENLEME: Eğlenmek istiyorsanız, yöntemlerinin yinelemeli tablo referansları için neden üstün olduğunu uzun uzun belirtmelerini sağlayın.

İki sütun her iki tabloda da aynı ada sahipse (kural # 2), SQL'de KULLANMA sözdizimini bir miktar yazma ve bazı standart gürültüyü kaydetmek için kullanabilirsiniz:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

2 numaralı sözleşmenin lehine olan bir başka argüman da ilişkisel modelin tasarlanma şeklidir .

Her sütunun önemi, kısmen karşılık gelen alanın adıyla etiketlenerek aktarılır.

Bence başvurunuzun nasıl bir araya getirildiğine bağlı. ORM kullanıyorsanız veya tablolarınızı nesneleri temsil edecek şekilde tasarlarsanız, seçenek 1 sizin için olabilir.

Veritabanını kendi katmanı olarak kodlamayı seviyorum. Her şeyi ben kontrol ediyorum ve uygulama sadece saklı prosedürleri çağırıyor. Özellikle çok sayıda tablo birleştirildiğinde ve birçok sütun döndürüldüğünde, tam sütun adlarına sahip sonuç kümelerine sahip olmak güzeldir. Bu uygulama türü ile seçenek 2'yi seviyorum. Sütun adlarının birleşimlerde eşleşmesini gerçekten seviyorum. Eşleşmedikleri eski sistemler üzerinde çalıştım ve bu bir kabustu.

Aşağıdakileri düşündünüz mü?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Her iki konvansiyon da her durumda işe yaramıyor, öyleyse neden bir tane var? Sağduyu kullanın...

Örneğin, kendine referans veren tablo için, aynı tablonun PK'sine kendi kendine referans veren birden fazla FK sütunu olduğunda, her iki "standardı" da ihlal etmeniz GEREKİR çünkü iki FK sütunu aynı şekilde adlandırılamaz ... örn. , EmployeeId PK ile EmployeeTable, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Aralarında seçim yapılacak çok az şey olduğuna katılıyorum. Bana göre her iki standartla ilgili çok daha önemli bir şey "standart" kısımdır.

İnsanlar 'kendi işlerini yapmaya' başlarlarsa, komşuları tarafından asılmalıdırlar. BENİM NACİZANE FİKRİME GÖRE :)

Çalıştığım yerde kullandığımız kural, tabloları çoğul biçimde adlandırmamız (yani, "çalışanlar") ve tablo ile sütun adı arasında alt çizgi kullanmamız dışında, A'ya oldukça yakındır. Bunun yararı, bir sütuna nasıl erişmek istediğinize bağlı olarak "çalışanlar _ kimliği" veya "çalışanlar.kimliği" şeklinde olmasıdır. Sütunun hangi tablodan geldiğini belirtmeniz gerekirse, "çalışanlar.employees _ id" kesinlikle gereksizdir.

Yalnızca veritabanı sorgularına değil, uygulama koduna da bakıyorsanız, bazı şeyler bana açık görünüyor:

1. Tablo tanımları genellikle doğrudan bir nesneyi tanımlayan bir sınıfa eşlenir, bu nedenle tekil olmaları gerekir. Bir nesnenin koleksiyonunu tanımlamak için genellikle tekil isme "Dizi" veya "Liste" veya "Koleksiyon" eklerim, çünkü çoğulların kullanımından daha açık bir şekilde bunun yalnızca bir koleksiyon olduğunu değil, aynı zamanda ne tür bir koleksiyon olduğunu da gösterir bu. Bu görünümde, koleksiyonun adı olarak değil, koleksiyon olduğu nesnenin türünün adı olarak bir tablo adı görüyorum. Uygulama kodunu yazmayan bir DBA bu noktayı kaçırabilir.

2. Ele aldığım veriler genellikle anahtar olmayan tanımlama amaçları için "Kimlik" kullanır. Anahtar "ID" ler ile anahtar olmayan "ID" ler arasındaki karışıklığı ortadan kaldırmak için, birincil anahtar adı için, tablo adı veya kısaltması ile "Anahtar" (bu, değil mi? tablo adı. Bu ön ek (ve bunu yalnızca birincil anahtar için saklıyorum) anahtar adını benzersiz kılar, bu özellikle önemlidir çünkü veritabanı sütun adlarıyla aynı değişken adları kullanıyoruz ve çoğu sınıfın adıyla tanımlanan bir ebeveyni var ana anahtar. Bu aynı zamanda, tek başına "Anahtar" olan ayrılmış bir anahtar kelime olmadığından emin olmak için de gereklidir. Anahtar değişken isimlerinin tutarlı tutulmasını kolaylaştırmak ve doğal birleşimler sağlayan programlar sağlamak, yabancı anahtarlar, birincil anahtar oldukları tabloda kullanılanlarla aynı ada sahiptir. Doğal birleştirmeler kullanarak bu şekilde daha iyi çalışan programlarla birden fazla karşılaştım. Bu son noktada, kullandığım kendine referans veren tablolarla ilgili bir sorun olduğunu kabul ediyorum. Bu durumda, yabancı anahtar adlandırma kuralına bir istisna yapardım. Örneğin, o tablodaki başka bir kaydı işaret etmek için Çalışan tablosunda bir yabancı anahtar olarak ManagerKey'i kullanırdım.

Kural 2'yi seviyorum - bu konuyu araştırırken ve kendi soruyu göndermeden önce bu soruyu bulurken, şu sorunla karşılaştım:

Çok sayıda sütunu olan bir tablodan * seçiyorum ve onu benzer şekilde çok sayıda sütunu olan ikinci bir tabloyla birleştiriyorum. Her iki tabloda da birincil anahtar olarak bir "id" sütunu vardır ve bu, sonuçta bu iki değeri benzersiz kılmak için her sütunu (bildiğim kadarıyla) özel olarak seçmem gerektiği anlamına gelir, yani:

SELECT table1.id AS parent_id, table2.id AS child_id

Kural 2'yi kullanmak, sonuçta hala aynı ada sahip bazı sütunlara sahip olacağım anlamına gelse de, artık ihtiyacım olan kimliği (ebeveyn veya çocuk) belirleyebilirim ve Steven Huwig'in önerdiği gibi, USINGifade işleri daha da basitleştirir.

Hep kullandım userId bir masa ve üzerinde bir olarak PK KullanıcıNo bir FK gibi başka masada. Birini diğerinden tanımlamak için userIdPK ve userIdFK'yi adlar olarak kullanmayı ciddi ciddi düşünüyorum . Tablolara bakarken PK ve FK'yi hızlı bir şekilde tanımlamama yardımcı olacak ve verilere erişmek için PHP / SQL kullanırken kodu temizleyerek anlaşılmasını kolaylaştıracak gibi görünüyor. Özellikle başkası koduma baktığında.

2 numaralı kuralı kullanıyorum. Şu anda, belirli bir tabloda ne anlama geldiğini bilmediğim eski bir veri modeliyle çalışıyorum. Ayrıntılı olmanın ne zararı var?

Yabancı anahtarı adlandırmaya ne dersiniz?

role_id

burada rol, başvurulan varlığın eldeki tabloyla göreli olduğu roldür. Bu, yinelemeli başvuru ve aynı tabloya birden çok fks sorununu çözer.

Çoğu durumda başvurulan tablo adıyla aynı olacaktır. Bu durumda, tekliflerinizden biri ile aynı hale gelir.

Her halükarda uzun tartışmalara sahip olmak kötü bir fikirdir

Order.employee_id = Employee.id ÜZERİNE çalışan INNER JOIN siparişinin "nerede" ek niteliklere ihtiyaç var mı? ".

Ek yeterliliğe gerek yok çünkü bahsettiğim yeterlilik zaten orada.

"Bir iş kullanıcısının Sipariş Kimliği veya Çalışan Kimliğine başvurmasının nedeni, bağlam sağlamaktır, ancak bir dabase düzeyinde zaten tabloya baktığınız için bağlamınız vardır".

Dua et, söyle bana, eğer sütunun adı 'ID' ise, o zaman bu "masaya hakemlik" tam olarak nasıl yapılır, bu referansı ID sütununa tam olarak bahsettiğim şekilde nitelemedikçe?