Veritabanı, Tablo ve Sütun Adlandırma Kuralları? [kapalı]

Bir veritabanı tasarladığımda, veritabanımda bir öğeyi adlandırmanın en iyi yolu olup olmadığını her zaman merak ediyorum. Sık sık kendime şu soruları soruyorum:

1. Tablo adları çoğul olmalı mı?
2. Sütun adları tekil olmalı mı?
3. Tablolara veya sütunlara ön ek eklemeli miyim?
4. Eşyaları adlandırırken herhangi bir durum kullanmalı mıyım?

Veritabanındaki öğeleri adlandırmak için önerilen herhangi bir kural var mı?

Microsoft'un SQL Server örnek veritabanlarına göz atmanızı öneririm: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorks örneği, veritabanı nesnelerinin organizasyonu için şema adlarını kullanan çok açık ve tutarlı bir adlandırma kuralı kullanır.

1. Tablolar için tekil isimler
2. Sütunlar için tekil isimler
3. Tablo öneki için şema adı (Örnek: SchemeName.TableName)
4. Pascal gövdesi (aka üst deve kılıfı)

Burada geç cevap, ama kısaca:

1. Benim tercihim çoğul
2. Evet
3. Tablolar : * Genellikle * hiçbir önek en iyisidir. Sütunlar : Hayır.
4. Hem tablolar hem de sütunlar: PascalCase.

detaylandırılması:

(1) Yapmanız gerekenler. Her seferinde belirli bir şekilde yapmanız gereken çok az şey var , ama birkaç tane var.

• Senin ad birincil anahtarları "[singularOfTableName] kimliği" biçimini kullanarak. Yani, tablo adınız Müşteri veya Müşteriler olsun , birincil anahtar MüşteriNo olmalıdır .
• Dahası, yabancı anahtarlar olmalıdır tutarlı adlandırılabilir farklı tablolarda. Bunu yapmayan birini dövmek yasal olmalıdır. Tanımlanmış yabancı anahtar kısıtlamaları genellikle önemli olmakla birlikte , tutarlı yabancı anahtar adlandırmasının her zaman önemli olduğunu bildiririm
• Veritabanınızın dahili kuralları olmalıdır . Daha sonraki bölümlerde beni, çok esnek olma göreceksiniz rağmen içinde bir veritabanı adlandırma çok tutarlı olmalıdır. Müşteriler için tablonuzun Müşteriler veya Müşteri olarak adlandırılması aynı veritabanında aynı şekilde yaptığınızdan daha az önemlidir. Ve alt çizgilerin nasıl kullanılacağını belirlemek için bir bozuk para çevirebilirsiniz, ancak daha sonra bunları aynı şekilde kullanmaya devam etmelisiniz . Bunu yapmazsanız, benlik saygısı düşük olması gereken kötü bir insansınız.

(2) Muhtemelen ne yapmalısınız.

• Farklı tablolardaki verilere aynı tür temsil Alanlar gerektiğini aynı adlandırılabilir. Bir tabloda Zip, diğerinde ZipCode yok.
• Tablo veya sütun adlarınızdaki kelimeleri ayırmak için PascalCasing kullanın. CamelCasing'i kullanmak asıl olarak sorunlu olmaz, ancak bu kural değildir ve komik görünecektir. Bir anda alt çizgilere değineceğim. (ALLCAPS'i eski günlerde olduğu gibi kullanamazsınız. OBNOXIOUSTABLE.ANNOYING_COLUMN DB2'de 20 yıl önce iyiydi, ama şimdi değil.)
• Kelimeleri yapay olarak kısaltmayın veya kısaltmayın. Bir ismin uzun ve net olması kısa ve kafa karıştırıcı olmaktan daha iyidir. Ultra kısa isimler, daha karanlık ve daha vahşi zamanlardan bir engeldir. Cus_AddRef. Bu dünyada ne var? Sorumlu Muhatap Başvurusu? Müşteri Ek İadesi? Özel Adres Yönlendirme?

(3) Dikkat etmeniz gerekenler.

• Gerçekten tablolar için çoğul isimleriniz olması gerektiğini düşünüyorum; bazıları tekil düşünüyor. Başka yerdeki argümanları okuyun. Ancak sütun adları tekil olmalıdır. Birden çok tablo adı kullansanız bile, diğer tabloların birleşimlerini temsil eden tablolar tekil olabilir. Örneğin, bir Promosyonlar ve Öğeler tablosunuz varsa, bir promosyonun parçası olan bir öğeyi temsil eden bir tablo Promotions_Items olabilir, ancak bence meşru bir şekilde Promotion_Items olabilir (bire çok ilişkisini yansıtır).
• Alt çizgileri tutarlı bir şekilde ve belirli bir amaç için kullanın. PascalCasing ile sadece genel tablo adları yeterince açık olmalıdır; kelimeleri ayırmak için alt çizgilere ihtiyacınız yoktur. Bir alt tabloyu, bir sonraki tabloya değineceğim ilişkisel tabloyu belirtmek için (a) veya önekleme için (b) alt çizgilerini kaydedin.
• Ön ek ne iyi ne de kötü. Bu genellikle iyi değil. İlk db veya ikinizde, tabloların genel tematik gruplaması için öneklerin kullanılmasını önermem. Tablolar, kategorilerinize kolayca sığmaz ve tablo bulmayı zorlaştırabilir . Tecrübe ile, zarardan daha iyi olan bir ön ek şeması planlayabilir ve uygulayabilirsiniz. Bir keresinde veri tablolarının tbl , ctbl ile yapılandırma tabloları , vew , proc'un sp ve udf's fn ile görünümleri ile başladığı bir db'de çalıştımve birkaçı; titizlikle, tutarlı bir şekilde uygulandı, bu yüzden iyi çalıştı. Önekleri GEREKTİREN tek zaman, bazı nedenlerden dolayı aynı db'de bulunan gerçekten ayrı çözümlere sahip olduğunuz zamandır; önek eklemek tabloları gruplandırmak için çok yararlı olabilir. Önekleme, öne çıkmak istediğiniz geçici tablolar gibi özel durumlar için de uygundur.
• Çok nadiren (eğer varsa) sütunların önekini yapmak istersiniz.

Tamam, görüşümüzle tartdığımız için:

Tablo adlarının çoğul olması gerektiğine inanıyorum. Tablolar varlıkların bir koleksiyonudur (bir tablo). Her satır tek bir varlığı ve tablo koleksiyonu temsil eder. Bu yüzden Kişi varlıklarına (ya da Kişilere, fantezi olan ne olursa olsun) bir tablo derim.

Sorgularda tekil "varlık adlarını" görmek isteyenler için, tablo takma adlarını şu şekilde kullanırdım:

SELECT person.Name
FROM People person

Biraz LINQ gibi "insanlar kişiden kişi seçin.

2, 3 ve 4 için, @Lars ile hemfikirim.

Üç DBA ile bir veritabanı destek ekibinde çalışıyorum ve dikkate alınan seçenekler şunlardır:

1. Herhangi bir adlandırma standardı hiçbir standarttan daha iyidir.
2. "Tek bir gerçek" standart yok, hepimizin tercihleri ​​var
3. Halihazırda yerinde standart varsa kullanın. Başka bir standart oluşturmayın veya mevcut standartları çamurlamayın.

Tablolar için tekil isimler kullanıyoruz. Tablolar, sistemin adıyla (veya kısaltmasıyla) ön ek eğilimi gösterir. Bu, sistem kompleksini tabloları mantıksal olarak birlikte gruplandırmak için öneki değiştirebileceğiniz için yararlıdır (örn. Reg_customer, reg_booking ve regadmin_limits).

Alanlar için alan adlarının tablonun önekini / akryonmunu içermesini bekleriz (örn. Cust_address1) ve ayrıca standart bir ekler dizisi (PK için _id, "kod" için _cd, "ad için _nm) kullanmayı tercih ederiz. "," sayı "için _nb," Tarih "için _dt).

Yabancı anahtar alanının adı, Birincil anahtar alanı ile aynı olmalıdır.

yani

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Yeni bir proje geliştirirken, tercih edilen tüm varlık adlarını, önekleri ve kısaltmaları yazmanızı ve bu belgeyi geliştiricilerinize vermenizi öneririm. Ardından, yeni bir tablo oluşturmaya karar verdiklerinde, tablonun ve alanların ne olarak adlandırılması gerektiğini "tahmin etmek" yerine belgeye başvurabilirler.

1. Hayır. Bir tablo, temsil ettiği varlıktan sonra adlandırılmalıdır. Kişi, kişi değil, kayıtlardan birinin temsil ettiği kişiyi nasıl ifade edeceğinizdir.
2. Yine aynı şey. FirstName sütunu gerçekten FirstNames olarak adlandırılmamalıdır. Her şey sütunla neyi temsil etmek istediğinize bağlıdır.
3. HAYIR.
4. Evet. Anlaşılır olması için bunu kullanın. "FirstName" gibi sütunlara ihtiyacınız varsa, kasa okumayı kolaylaştırır.

Tamam. Bu benim 0.02 dolarım

Ayrıca, ISO / IEC 11179 stil adlandırma kuralından da bahsediyorum, kuralcı olmaktan ziyade kurallar olduklarını belirtmek.

Wikipedia'da Veri öğesi adı konusuna bakın :

"Tablolar Varlık Koleksiyonlarıdır ve Koleksiyon adlandırma yönergelerini takip eder. İdeal olarak, kolektif bir ad kullanılır: örn., Personel. Çoğul da doğrudur: Çalışanlar. Yanlış adlar şunları içerir: Çalışan, tblEmployee ve EmployeeTable."

Her zaman olduğu gibi, kurallarda istisnalar vardır, örneğin her zaman tam olarak bir satırı olan bir tablo tekil bir adla daha iyi olabilir, örneğin bir yapılandırma tablosu. Tutarlılık son derece önemlidir: Dükkanınızın bir sözleşmeye sahip olup olmadığını kontrol edin ve eğer öyleyse izleyin. Eğer beğenmediyseniz, yalnız ranger olmak yerine değişmesi için bir iş vakası yapın.

Bir masanın çoğullaştırılıp çoğaltılmamasının tamamen kişisel zevk meselesi olduğu ve en iyi uygulama olmadığı iddiasını her zaman duyuyorum. Bunun doğru olduğuna inanmıyorum, özellikle de bir DBA'nın aksine bir programcı olarak. Bildiğim kadarıyla, tek bir tablo isimleri alarak kodda meşru kazançlar varken, "Benim için mantıklı çünkü bu bir nesne koleksiyonu" dışında bir tablo adını çoğullamak için meşru bir neden yoktur. Örneğin:

1. Çoğul belirsizliklerin neden olduğu hataları ve hataları önler. Programcılar yazım uzmanlıklarıyla tam olarak bilinmemektedir ve bazı kelimeleri çoğaltmak kafa karıştırıcıdır. Örneğin, çoğul sözcük 'es' ya da sadece 's' ile bitiyor mu? Kişiler mi insanlar mı? Büyük ekiplerle bir proje üzerinde çalışırken, bu bir sorun haline gelebilir. Örneğin, ekip üyesinin oluşturduğu bir tabloyu çoğaltmak için yanlış yöntemi kullandığı bir örnek. Ben bu tablo ile etkileşim zaman, ben erişimi yok veya düzeltmek için çok uzun sürecek kod baştan baştan kullanılır. Sonuç olarak, her kullandığımda masayı yanlış hecelemeyi hatırlamalıyım. Buna çok benzer bir şey başıma geldi. Ekibin her üyesinin tutarlı ve kolay bir şekilde tam olarak kullanmasını kolaylaştırabilir, tablo adlarını hatasız olarak düzeltmek veya tablo adlarını her zaman aramak zorunda kalmak daha iyidir. Tekil versiyonun ekip ortamında kullanımı çok daha kolaydır.

2. Bir tablo adının tekil sürümünü kullanıyorsanız VE birincil anahtarın adını tablo adıyla ön eklerseniz, artık birincil anahtardan bir tablo adını kolayca belirleme avantajına sahip olursunuz. İçinde tablo adı olan bir değişken verilebilir, sonuna "Id" değerini birleştirebilir ve artık tablonun birincil anahtarını ek bir sorgu yapmanıza gerek kalmadan kod aracılığıyla alabilirsiniz. Veya kod aracılığıyla bir tablo adı belirlemek için birincil anahtarın sonundaki "Kimlik" i kesebilirsiniz. Birincil anahtar için tablo adı olmadan "id" kullanırsanız, kod aracılığıyla birincil anahtardan tablo adını belirleyemezsiniz. Buna ek olarak, tablo adlarını çoğullayan ve PK sütunlarını tablo adıyla önek olarak kullanan çoğu kişi, PK'da tablo adının tekil sürümünü kullanır (örneğin, durumlar ve status_id),

3. Tablo adlarını tekil yaparsanız, temsil ettikleri sınıf adlarıyla eşleşmelerini sağlayabilirsiniz. Bir kez daha, bu kodu basitleştirebilir ve tablo adından başka bir şeye sahip olmadan bir sınıfı başlatmak gibi gerçekten düzgün şeyler yapmanıza izin verebilir. Ayrıca, kodunuzu daha tutarlı hale getirir, bu da ...

4. Tablo adını tekil yaparsanız, adlandırma düzeninizi tutarlı, düzenli ve her yerde bakımı kolay hale getirir. Kodunuzdaki her örnekte, ister sütun adında, ister sınıf adı olarak, ister tablo adı olarak, aynı adın aynısı olduğunu bilirsiniz. Bu, verilerin kullanıldığı her yeri görmek için genel aramalar yapmanıza olanak tanır. Bir tablo adını çoğullaştırdığınızda, o tablo adının tekil sürümünü (birincil anahtarda dönüştüğü sınıf) kullanacağınız durumlar olacaktır. Verilerinizin çoğul olarak adlandırıldığı bazı örneklerin ve bazı örneklerin tekil olduğu anlamına gelmez.

Özetlemek gerekirse, tablo adlarınızı çoğulluyorsanız, kodunuzu daha akıllı ve kullanımı daha kolay hale getirmenin her türlü avantajını kaybedersiniz. Tablo adlarınızı nesnelerden veya kaçınabileceğiniz yerel kod adlarına dönüştürmek için arama tablolarına / dizilere sahip olmanız gereken durumlar bile olabilir. Tekil tablo isimleri, belki de başlangıçta biraz garip hissetmelerine rağmen, çoğullaştırılmış isimlere göre önemli avantajlar sunar ve en iyi uygulama olduğuna inanıyorum.

bizim tercihimiz:

1. Tablo adları çoğul olmalı mı?
   Asla. Bir koleksiyon olduğu argümanları mantıklıdır, ancak tablonun ne içereceğini asla bilemezsiniz (0,1 veya daha fazla öğe). Çoğul kurallar, adlandırmayı gereksiz yere karmaşık hale getirir. 1 Ev, 2 ev, fare vs fare, kişi vs insan ve biz başka bir dile bakmadık bile.

   Update person set property = 'value'tablodaki her bir kişiye etki eder.
   Select * from person where person.name = 'Greg'kişi satırlarının bir koleksiyonunu / satır kümesini döndürür.

2. Sütun adları tekil olmalı mı?
   Genellikle, normalleştirme kurallarını ihlal ettiğiniz yerler dışında evet.

3. Tablolara veya sütunlara ön ek eklemeli miyim?
   Çoğunlukla bir platform tercihi. Sütunlara tablo adını önek eklemeyi tercih ediyoruz. Tabloların önekini kullanmıyoruz, ancak önek görünümlerini (v_) ve depolanan_prosedürleri (sp_ veya f_ (işlev)) yapıyoruz. Bu, aslında bir görünümde hesaplanmış bir alan olan v_person.age'yi güncellemeye çalışmak isteyen kişilere yardımcı olur (yine de UPDATEd olamaz).

   Ayrıca, anahtar kelime çarpışmasını önlemek için harika bir yoldur (delivery.from sonları, ancak delivery_from bunu engellemez).

   Kodu daha ayrıntılı hale getirir, ancak genellikle okunabilirliğe yardımcı olur.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... çok okunaklı ve açık. Bu yine de kontrolden çıkabilir:

   customer.customer_customer_type_id

   müşteri ile customer_type tablosu arasındaki ilişkiyi belirtir, customer_type tablosundaki (customer_type_id) birincil anahtarı belirtir ve bir sorguda hata ayıklarken 'customer_customer_type_id' görürseniz anında (müşteri tablosu) olduğunu bilirsiniz.

   veya customer_type ve customer_category arasında MM ilişkiniz varsa (belirli kategoriler için yalnızca belirli türler kullanılabilir)

   customer_category_customer_type_id

   ... uzun tarafta biraz (!).

4. Eşyaları adlandırırken herhangi bir durum kullanmalı mıyım? Evet - küçük harf :), alt çizgilerle. Bunlar çok okunabilir ve çapraz platformdur. Yukarıdaki 3 ile birlikte de mantıklı.

   Bunların çoğu yine de tercihler. - Tutarlı olduğunuz sürece, okuması gereken herkes için tahmin edilebilir olmalıdır.

ISO 11179-5'e bakın: Adlandırma ve tanımlama ilkeleri Buradan edinebilirsiniz: http://metadata-standards.org/11179/#11179-5

Burada bir süre blog yazdım : ISO-11179 Adlandırma Kuralları

Bunun oyuna geç olduğunu biliyorum ve soru zaten çok iyi cevaplandı, ancak sütun adlarının ön eki hakkında # 3 hakkında görüşümü sunmak istiyorum.

Tüm sütunlar, tanımlandıkları tabloya özgü bir önekle adlandırılmalıdır.

Örneğin, tablolar "müşteri" ve "adres" olarak, sırasıyla "cust" ve "addr" önekleriyle gidelim. "müşteri" içinde "cust_id", "cust_name" vb. olur. "adres" içinde "addr_id", "addr_cust_id" (müşteriye geri FK), "addr_street" vb.

Bu standarda ilk sunulduğumda, ona karşı çıkmıştım; Bu fikirden nefret ettim. Tüm bu ekstra yazma ve artıklık fikrine dayanamadım. Şimdi onunla asla geri dönmeyeceğim kadar deneyimim oldu.

Bunu yapmanın sonucu, veritabanı şemanızdaki tüm sütunların benzersiz olmasıdır. Buna karşı tüm argümanları koyan büyük bir yararı var (bence, elbette):

Tüm kod tabanınızı arayabilir ve belirli bir sütuna dokunan her kod satırını güvenilir bir şekilde bulabilirsiniz.

# 1'in yararı inanılmaz derecede büyük. Bir sütunu kullanımdan kaldırabilir ve sütunun güvenli bir şekilde şemadan kaldırılabilmesi için hangi dosyaların güncellenmesi gerektiğini tam olarak bilirim. Bir sütunun anlamını değiştirebilir ve tam olarak hangi kodun yeniden düzenlenmesi gerektiğini bilirim. Veya bir sütundaki verilerin sistemin belirli bir bölümünde kullanılıp kullanılmadığını bile söyleyebilirim. Bunun potansiyel olarak büyük bir projeyi kaç kez basit bir projeye dönüştürdüğünü ya da geliştirme çalışmalarında ne kadar tasarruf ettiğimizi sayamıyorum.

Bunun nispeten küçük bir yararı da, sadece kendi kendine birleştirme yaptığınızda tablo takma adları kullanmanızdır:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Bunlar hakkında görüşlerim:

1) Hayır, tablo adları tekil olmalıdır.

Basit seçim ( select * from Orders) için anlamlı gibi görünse de , OO eşdeğeri ( Orders x = new Orders) için daha az anlamlıdır .

DB'deki bir tablo gerçekten de bu varlığın kümesidir, set-mantık kullandığınızda daha mantıklıdır:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Bu son satır, birleştirmenin gerçek mantığı, çoğul tablo adlarıyla karıştırılır.

Her zaman bir takma ad kullanma konusunda emin değilim (Matt'in önerdiği gibi) bunu temizler.

2) Sadece 1 mülkü olduğu için tekil olmalıdırlar

3) Asla, sütun adı belirsizse (her ikisinin de [Key] adında bir sütuna sahip olduğu gibi) tablonun adı (veya diğer adı) bunları yeterince iyi ayırt edebilir. Sorguların hızlı yazılmasını ve basit öneklerin gereksiz karmaşıklığı artırmasını istiyorsunuz.

4) Ne istersen, CapitalCase'i öneririm

Bunların hiçbirinde bir dizi mutlak yönerge olduğunu sanmıyorum.

Ne olursa olsun seçim uygulama veya DB tutarlı olduğu sürece gerçekten önemli olduğunu sanmıyorum.

Bence:

1. Tablo adları çoğul olmalıdır.
2. Sütun adları tekil olmalıdır.
3. Hayır.
4. Tablo adları ve sütun adları için CamelCase (tercih ettiğim) veya alt çizgi_ayrı.

Ancak, daha önce de belirtildiği gibi, herhangi bir sözleşme, hiçbir sözleşmeden daha iyidir. Nasıl yapmayı seçerseniz seçin, gelecekteki değişikliklerin aynı kuralları izlemesi için belgeleyin.

Bu soruların her birine en iyi cevabın siz ve ekibiniz tarafından verileceğini düşünüyorum. Bir adlandırma kuralına sahip olmak, adlandırma kuralının tam olarak ne olduğundan çok daha önemlidir.

Buna doğru bir cevap olmadığından, biraz zaman ayırmalısınız (çok fazla değil) ve kendi sözleşmelerinizi seçmelisiniz ve - işte önemli kısım - buna bağlı kalmalısınız .

Tabii ki, bununla ilgili standartlar hakkında bazı bilgiler aramak iyidir, bu da sorduğunuz şeydir, ancak alabileceğiniz farklı cevapların sayısı konusunda endişelenmeyin veya endişelenmeyin: sizin için daha iyi görünen cevabı seçin.

Her ihtimale karşı, işte cevaplarım:

1. Evet. Bir tablo bir grup kayıt , öğretmen veya aktör , yani ... çoğul.
2. Evet.
3. Onları kullanmıyorum.
4. Daha sık kullandığım veritabanı - Firebird - her şeyi büyük harflerle saklıyor, bu yüzden önemli değil. Her neyse, programlarken, adları releaseYear gibi okunması daha kolay olacak şekilde yazıyorum .

1. Kesinlikle tablo isimlerini tekil tutun, kişi insanları değil
   2. Burada aynı
   3. Hayır. Bazı korkunç önekler gördüm, şu ana kadar uğraştığınızı belirtecek bir tablo (tbl_) veya bir kullanıcı deposu prosedürü (usp_). Bunu veritabanı adı izliyor ... Yapma!
   4. Evet. Tüm tablo adlarımı PascalCase'e yöneltiyorum

Adlandırma kuralları, geliştirme ekibinin projenin kalbinde keşfedilebilirlik ve sürdürülebilirlik tasarlamasına olanak tanır.

İyi bir adlandırma kuralı gelişmek için zaman alır, ancak bir kez yerine oturduğunda ekibin ortak bir dille ilerlemesine izin verir. İyi bir adlandırma kuralı proje ile organik olarak büyür. İyi bir adlandırma kuralı, yazılım yaşam döngüsünün en uzun ve en önemli aşamasındaki değişikliklerle kolayca başa çıkabilir - üretimde hizmet yönetimi.

İşte cevaplarım:

1. Evet, tablo adları, örneğin bir dizi işlem , menkul kıymet veya karşı tarafa atıfta bulunduğunda çoğul olmalıdır .
2. Evet.
3. Evet. SQL tablolarının önüne tb_, görünümlerin önüne vw_, saklı yordamların önüne usp_ ve tetikleyicilerin önüne tg_ ve ardından veritabanı adı gelir.
4. Sütun adı alt çizgi ile küçük harfle ayrılmalıdır.

Adlandırma zordur, ancak her organizasyonda bir şeyleri adlandırabilecek biri vardır ve her yazılım ekibinde adlandırma standartları için sorumluluk alan ve sec_id , sec_value ve security_id gibi adlandırma sorunlarının projeye hazırlanmadan önce çözülmesini sağlayan biri olmalıdır. .

Peki, iyi bir adlandırma kuralı ve standartlarının temel ilkeleri nelerdir:

• İstemcinizin dilini ve çözüm alanınızı kullanın
• Açıklayıcı olun
• Tutarlı olun
• Belirsizlik, yansıtma ve yeniden düzenleme
• Herkese açık olmadıkça kısaltmalar kullanmayın
• SQL ayrılmış anahtar kelimeleri sütun adı olarak kullanma

İşte size birkaç seçenek sunan bir bağlantı. Kısmen tanımlanmış olana güvenmek yerine takip edebileceğim basit bir özellik arıyordum.

http://justinsomnia.org/writings/naming_conventions.html

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Tablo adları her zaman tekil olmalıdır, çünkü bir dizi nesneyi temsil ederler. Dediğin gibi sürüyü bir grup koyun ya da sürüyü belirtmek için bir grup kuş belirtin. Çoğullamaya gerek yok. Bir tablo adı iki adın bileşimi olduğunda ve adlandırma kuralı çoğul olduğunda, çoğul adın ilk sözcük mü yoksa ikinci sözcük mü yoksa her ikisi mi olduğunu bilmek zorlaşır. Bu mantık - Object.instance, objects.instance değil. Veya TableName.column, TableNames.column (lar) değil. Microsoft SQL büyük / küçük harfe duyarlı değildir, büyük veya küçük harfler kullanılıyorsa, iki veya daha fazla addan oluşan tablo veya sütun adlarını ayırmak için tablo adlarını okumak daha kolaydır.

Tablo Adı: Tekil olmalıdır, çünkü gerçek dünya nesnesini temsil eden tekil bir varlıktır ve tekil olan nesneleri değil.

Sütun Adı: Ancak o zaman tekil olmalı, atomik bir değeri tutacağını ve normalleşme teorisini doğrulayacağını iletir. Bununla birlikte, aynı sayıda özellik türü varsa, bunların 1, 2, ..., n, vb. İle eklenmesi gerekir.

Önek Tablolar / Sütunlar: Bu çok büyük bir konudur, daha sonra tartışılacaktır.

Gövde: Deve kasası olmalı

Arkadaşım Patrick Karcher , sizden, yazdığınız gibi birine rahatsız edici olabilecek hiçbir şey yazmamanızı rica ediyorum, “• Ayrıca, yabancı anahtarlar farklı tablolarda sürekli olarak adlandırılmalıdır. Bunu yap.". Bu hatayı hiç yapmadım arkadaşım Patrick, ama genelde yazıyorum. Ya birlikte bunun için seni dövmeyi planlıyorlarsa? :)

Partiye çok geç ama yine de sütun önekleri hakkında iki sent eklemek istedim

Sütunlar için table_column (veya tableColumn) adlandırma standardını kullanmak için, her ikisi de sütun adının kendisinin tüm veritabanınızda benzersiz olacağı gerçeğine dayanarak iki ana argüman olduğu görülmektedir:

1) Sorgularınızda her zaman tablo adları ve / veya sütun takma adları belirtmeniz gerekmez

2) Tüm kodunuzu sütun adı için kolayca arayabilirsiniz

Her iki argümanın da kusurlu olduğunu düşünüyorum. Ön ek kullanmadan her iki sorunun da çözümü kolaydır. İşte teklifim:

Her zaman SQL'inizdeki tablo adını kullanın. Örneğin, her zaman sütun yerine table.column kullanın.

Açıkçası 2'yi çözüyor) çünkü artık table_column yerine table.column öğesini arayabilirsiniz.

Ama çığlık duyabiliyorum, nasıl çözüyor 1)? Tam olarak bundan kaçınmakla ilgiliydi. Evet, öyleydi, ama çözüm korkunç bir şekilde kusurluydu. Neden? Peki, önek çözümü
şuna bağlanır: Belirsizlik olduğunda table.column öğesini belirtmekten kaçınmak için, tüm sütunlarınızı table_column olarak adlandırırsınız!
Ancak bu, her zaman bir sütun belirttiğinizde HER ZAMAN sütun adını yazmanız gerektiği anlamına gelir. Ama yine de bunu yapmak zorundaysanız, her zaman açıkça table.column yazmanın faydası nedir? Tam olarak, hiçbir faydası yok, yazmak için aynı sayıda karakter var.

edit: evet, önek ile sütunları isimlendirme doğru kullanımı zorlarken farkındayken benim yaklaşım programcılar dayanmaktadır

Temel Veritabanı Adlandırma Kuralları (ve Stil) (daha ayrıntılı açıklama için buraya tıklayın)

tablo isimleri kısa, açık isimler seçer, bir veya iki kelimeden daha fazlasını kullanmaz, tabloları ayırt etmek, benzersiz alan adlarının isimlendirilmesini kolaylaştırır, ayrıca arama ve bağlantı tabloları tabloları tekil isimler verir, asla çoğalmaz (güncelleme: hala verilen nedenlere katılıyorum Bu kongre için, ancak çoğu insan çoğul masa isimlerini gerçekten seviyor, bu yüzden duruşumu yumuşattım) ... yukarıdaki bağlantıyı takip edin lütfen

Tablo adları tekil. Diyelim ki birisi ile adresi arasında bir ilişkiyi modellediniz. Örneğin, bir veri modeli okuyorsanız, 'her kişi 0,1 veya daha fazla adreste yaşayabilir' seçeneğini tercih ederdiniz. veya 'her kişi 0,1 veya daha fazla adreste yaşayabilir.' İnsanları kişi olarak yeniden ifade etmek yerine adresi çoğullamak daha kolay olduğunu düşünüyorum. Ayrıca kolektif isimler genellikle tekil versiyon için dezavantajlıdır.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Bunlar bana öğretilen sözleşmelerdir, ancak geliştirme hortumunun kullandığı her şeye uyum sağlamalısınız.

1. Çoğul. Varlıkların bir koleksiyonudur.
2. Evet. Özellik, bir varlığın tekil mülkiyetinin bir temsilidir.
3. Evet, önek tablosu adı, tüm kısıtlama dizinlerinin ve tablo diğer adlarının kolayca izlenebilir adlandırılmasına olanak tanır.
4. Tablo ve sütun adları için Pascal Durumu, dizinler ve kısıtlamalar için önek + TÜM başlıklar.