Veritabanındaki sütunları etiketlemenin etkili bir yolu nedir?

Veri tabanlarımdaki sütunları şöyle etiketlerdim:

user_id
user_name
user_password_hash

İki masaya katılırken uyuşmazlıktan kaçınmak için, ancak daha sonra masaları takma ad konusunda daha fazla şey öğrendim ve bunu yapmayı bıraktım.

Veritabanındaki sütunları etiketlemenin etkili bir yolu nedir? Niye ya?

Senin durumunda, önek kullanıcısı gereksiz. Biz (sorumlu olan devs) bunun masa kullanıcısı olduğunu biliyor, öyleyse neden user_her alanın önüne ön ek eklesin?

Sana önereceğim şey, daha doğal bir yaklaşımla yapmak.

Kişinin özellikleri nelerdir: Soyadı, Adı, Doğum Tarihi, Uyruğu vb.

Otomobilin özellikleri nelerdir: Model, Yıl, Renk, Enerji, vb ...

Sütununuz olabildiğince doğal olarak adlandırılmalıdır, şemayı herkes için, sizin ve kendinizden sonra gelenler için daha net hale getirecektir. Buna Bakım aşaması da denir ve bakımı kolaylaştırmak için yapabileceğiniz her şey genellikle çabaya değer.

Spredzy'nin yorumuna ek olarak, birincil anahtarlarınızı aynı (ID) olarak etiketleyin; böylece anında sorgulamalar yazarken, kolayca arama yapmak yerine (u.ID = c.ID) hatırlayabilirsiniz. , country_ID, countries_ID, countriesID,? "

David Hall'ın Spredzy'nin mükemmel cevabına yaptığı eklere daha fazla katılamazdım. Basit ve doğal gitmek için yoludur. Tabloları doğal olarak da adlandırırsanız, tablo karışıklığı bir sorun olmamalıdır.

Users.id ve cars.id öğelerini kullanabildiğiniz zaman users.user_id ve cars.car_id adreslerine sahip olmanın anlamı yok.

Bir veritabanı şemasında, her sütunun tablolar arasında benzersiz bir adı olması gerektiğini savunuyorum. Bunun birkaç nedeni var:

• Modelleme bakış açısıyla: Nitelikler çorbasıyla başlıyorsunuz ve tabloları normalleştiriyorsunuz. Zamanla, daha fazla normalleştirebilir veya normalleştirebilir veya görünümler veya somutlaştırılmış görünümler getirebilir veya yeni tablolar sunabilirsiniz. Tüm sütun adları benzersizse, bu hiçbir zaman sorun olmaz.

• Bu birleşim sözdizimini kullanabilirsiniz: a JOIN b USING (a_id) JOIN c USING (a_id). Çok rahat ve aynı zamanda aşağıdaki nokta ile yardımcı olur.

• Çok fazla sayıda SELECT *katılımcının olduğu sorgular çalıştırırsanız veya materyalize görüşler yaratırsanız , asla (iyi, belki de nadiren) bir çatışmanız olmaz. Katılmadan düşünün person.name, product.name, country.namevb Urgh.

• Genel olarak, büyük sorgularınız varsa, idher yerde ne anlama geldiğini takip etmek zordur .

Bakalım, örneğinizle şunun gibi görünecek:

USERS
----
id
username,
password
registration_date

Tablo adını büyük harflerle kullanırım. Bu, masayı kolayca tanımlamama izin veriyor. Az önce adlandırdığım sütunların her biri temsil ettiği şey için. Sayı kullanmamayı veya onunla herhangi bir önek veya sonek eklememeyi deniyorum. Bu, sorguların basit ve oldukça basit bir şekilde yapılmasını sağlar.

Btw, bence beğeneceğin bir stil bulmalısın ve buna sadık kalmalısın. Sık sık değiştirirseniz, daha sonra bir dağınık DB şemasına sahip olursunuz.

Diğerleri gibi, tablo adını sütunun bir parçası olarak eklememenizi öneririz. Çoğunlukla benzer sütun adlarına sahip yüzlerce tablonuz yoksa: hepsi bir sütun başlıklı birden fazla düzinelerce tablonuz varsa, tabiki bunları tablonun önüne tablo adı ile ekleyin.

Geçenlerde geliştiricilerin birinin birincil anahtar ve yabancı anahtar sütunlarını pk ve fk ile ön eklemeyi tercih ettiği bir şirketten ayrıldım. Bu, sütunların pkfk ile başladığı bazı abominasyonlara yol açar (genellikle bir sütunu diğer tabloya yabancı anahtar olan 2 sütunu temel alan bileşik bir birincil anahtar).

Her sütun adının tablo adından türetilen bir önekle başladığı bir ortamda çalışıyorum, bu benim buluşum değil, ancak bundan çok mutluyum.

İdeal olarak sütun adları, veritabanındaki tüm tablolarda benzersizdir.

Bazı gözlemler:

• Bir tablodaki tabloyu bir select deyiminde birden çok kez birleştirdiğinizde sadece tablo takma adlarına ihtiyacımız var
• Kod parçacıklarını kopyalarken bazı hataları önler, çünkü sütun adlarının tablo adına uyarlanması gerekir
• Bir yabancı anahtar sütununun hangi tabloya işaret ettiğini göstermeye yardımcı olur

Genel fikirler: En önemlisi, her adlandırma kuralının tutarlılığıdır: - tekil ve çoğul (tablolar için geçerli olan ve sütunlar için geçerli değildir) - birincil ve yabancı anahtarları belirleyin (yapıyı veritabanının içeriğine göre oluştururlar) - ne zaman tutarlı olun dizeleri ve aynı dizinin kısa değişkenini saklarsanız, bayraklar, durum vb. ile tutarlı olun.

Spredzy'nin cevabı ile aynı fikirdeyim, ancak tercih olarak, under_score yerine camelCase kullanacağımı da ekleyeceğim.

firstName, lastName vb.

Oracle durumda, isteyeceksiniz değil kolon'durumuna kimlik "veya 'adını' ya da jenerik herhangi bir isim.

Mesele şu ki , eski sürümlerde varsayılan olarak Oracle, benzer sütun adlarına dayanan tabloları birleştirmeye çalışacak, bu yüzden her şeyi iyi bir şekilde adlandırdıysam, tablolarım arasında varsayılan birleştirme yan tümcesini belirleyerek de sona erdi.

Hatta Ama eğer değil birden tablolarda görünür isimleri seçilmesi vermeyerek, Oracle kullanarak, aynı zamanda araç daha sonra bir iki tablo arasında seçmek yapmanız gereken her zaman aliasing sorun üzerinden gitmek zorunda kalmamasıdır:

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

Bu nedenle, eğer çoklu tablo seçimleri norm ise, daha uzun sütun isimleri sizi yazarken saklar. (bir seferde sadece bir tablo kullanıyorsanız ... gerçekten bir ilişkisel veritabanına ihtiyacınız var mı?)

... ve kaydetme yazma, bizi Oracle'da başka bir soruna getiriyor - en azından 8i'de (Oracle SQL Tuning ve Veri Modelleme derslerini alırken şu anki sürüm) yürütme planlarının önbelleğe alınması, yalnızca ilk o kadar çok karaktere dayanıyor: sorgusu (tam değerini hatırlayamıyorum ... 1024?), öyleyse, cümlenin sonunda yalnızca bir şeyden farklı olan sorgularınız ve çıkardığınız sütunların gerçekten uzun bir listesi varsa, yürütme planını doğru önbelleğe alamadığı için performansa çarpabilir.

Oracle, iyi bir masa ve sütun adı olduğunu iddia ettiklerini seçme konusunda bir rehbere sahipti, bu temelde 5-8 karaktere kadar harfleri kaldırmak için bir rehberdi, ama ben hiç umursamadım.

...

Her şey bundan başka bir şey olarak giderken:

• sütunlar her zaman tekildir (tablolar her zaman çoğuldur)
• Tüm isimler küçük harflerdir, sadece büyük küçük harf duyarlı bir şey olması durumunda
• Yukarıdakilerin bir sonucu olarak, deve çantası yerine alt çizgi kullanın.

güncelleme : Oracle'ın birleştirme davranışına aşina olmayanlar için, şu şekilde bahsettiği Oracle SQL Mastering: Join Koşulları hakkındaki son örneğe bakın :

Ne oldu? Bunun nedeni, supplier_id dışında, bu iki tablonun ortak bir isimle başka bir sütun çiftinin olması gerçeğinde yatmaktadır. Bu sütun isimdir. Bu nedenle, tedarikçi ile parça tabloları arasında doğal bir birleşme isteğinde bulunduğunuzda, birleşme işlemi sadece iki tablonun supplier_id sütununu eşitlemekle kalmaz, aynı zamanda iki tablonun isim sütunu da eşittir. Hiçbir tedarikçi adı aynı tedarikçinin parça adıyla aynı olmadığından, sorgu tarafından hiçbir satır döndürülmez.

'Eski birleştirme sözdizimi' altında (8i ve önceki), 'DOĞAL BİRLEŞTİRME' varsayılan birleştirme davranışıydı ve bir birleştirme koşulu belirtmemenizin hala geçerli olduğuna inanıyorum. 'NATURAL JOIN' bir kez 9i'de resmi bir seçenekti, genel öneri kullanmıyordu , çünkü kötü sütun isimleri sizi mahvedebilirdi, ki bu benim iyi sütun isimlerini savunuyorum.

1. Asla çift tırnak kullanmayın, "çünkü bunu yaparken, veritabanının yerel büyük / küçük harf katlamasını geçersiz kılarsınız. SQL spec tüm tanımlayıcıları büyük harfe katlamayı gerektirir. PostgreSQL gibi bazı veritabanları bunları küçük harfe katlar. Hiçbir şey belirtilmezse, tüm veritabanlarında çalışır ve bunları spec veya rdbms'ye özgü varsayılan değere katlayabilirler.
2. Bir under_score ( _) kullanın , çünkü yukarıdakilere göre - camelCase kullanmamalısınız.

3. kullanmak {entity}_id(bu kimlikleri işaret ve yabancı anahtarları) kimlikleri için. Çünkü o zaman USINGmaddeyi kullanabilirsiniz . Birleştirme koşullarında kullanılan dünya çapında benzersiz anahtar isimler şartnamede belirlenmiş bir konvansiyondur.

   SELECT *
   FROM employee
   INNER JOIN department
     USING (department_id);
   
     -- compare to
     ON employee.department_id = department.department_id;