Tablo Adlandırma İkilemi: Tekil ve Çoğul İsimler [kapalı]

1466

Academia, tablo adlarının özelliklerini depoladıkları varlığın tekil olması gerektiğini düşünüyor.

İsimler etrafında köşeli parantez gerektiren herhangi bir T-SQL sevmiyorum, ama Userssonsuza kadar bazen parantez kullanmak zorunda tabloyu kullananlara hüküm veren bir tabloyu tekil olarak yeniden adlandırdım .

Bağırsak hissim, tekil kalmanın daha doğru olduğudur, ancak bağırsak hissim, köşeli parantezlerin, boşlukları olan sütun adları gibi istenmeyenleri belirtmesidir.

Kalmalı mıyım yoksa gitmeli miyim?

sql sql-server naming-conventions

— ProfK
kaynak

Çoğul veya tekil olarak adlandırılan önceki Veritabanı tablolarının çoğunu , ancak bu daha fazla dikkat çekti.

— outis

7

Daha fazla insanın söylemediğine şaşırdım: tek bir sıranın neyi temsil ettiği belirlenir. Tek bir veritabanında, satırları tek bir widget'ı temsil eden bir tablo olabilir ve bu tabloyla bire-çok ilişkisi olan başka bir satır, satırların birçok widget'ı temsil ettiği anlamına gelir. Bunu yapmamak ifade gücünü kaybeder.

— andygavin

1

Sadece bu tartışmaların hepsinde, bir tablonun hiçbir şekilde bir sınıfla aynı şekilde şekillenmediğini veya form oluşturmayacağını unutmayın. Tablo, ayrı ayrı özellikler üzerinde sıralanabilen, sorgulanabilen vb. Belirli bir türdeki öğelerin bir koleksiyonudur. Sınıf, belirli bir türün özelliklerini ve davranışını tanımlayan çerçevedir. OO kodlama terimlerinde, bir tablonun kapanış temsili bir nesneler topluluğudur (hangi ORM'yi kullanıyor olursanız olun). Bu, bu konuda bugüne kadarki en yüksek dereceli google cevabıdır, bu nedenle soru kapalı olmasına rağmen, sayfanın hala değeri vardır.

1

Çalıştığınız ekosistemin ortak pratiğini yapardım. Örneğin: Nohel.js'de Bookshelf.js veya Objection.js gibi ORM'lerde esas olarak "Knex.js" temel alınmıştır. Ve "Knex.js" belgelerinde çoğul olarak tablo adlarını bulacaksınız. Ben de o alanda çoğul yapmayı tercih ederim. Kaynak: knexjs.org/#Schema-createTable

— Benny Neugebauer

2

Evet katılıyorum. Bu kullanıcıların bir tablo var ve bu da "UserRules" kullanıcı belirli bir türü için geçerli kuralların bir tablo var ve onu aramaya mantıklı aynı anda "APPUSER kimliğine" diyoruz mantıklı

— Arindam

242

Diğerleri "standartlar" kadarıyla oldukça iyi cevaplar verdim, ama ben sadece bunu eklemek istedim ... "Kullanıcı" (veya "Kullanıcılar") aslında tabloda tutulan verilerin tam bir açıklama olması mümkün mü ? Tablo adları ve özgüllüğü ile çok çıldırmanız değil, belki de "Widget_Users" ("Widget" uygulamanızın veya web sitenizin adıdır) gibi bir şey daha uygun olacaktır.

— Tom H
kaynak

7

Katılıyorum. Kuruluşlar, Uygulayıcılar, anahtar kelime kullanmaktan kaçınmak için her şey.

— MikeW

7

-1. Tablo Kullanıcıları (ve Ülkeler, Diller) birkaç uygulamada aynı anda kullanılabilir.

— OZ_

129

Şema adını ilişkilendirmek tüm karışıklığı ortadan kaldırmaz mı? AppName1.Users, AppName2.Users?

— Zo

7

Tablo önekine katılmıyorum - belki de bir şema olmalı? - ama "daha açıklayıcı bir isim" ile aynı fikirdeyim Tüm ad alanı tartışmasına girmeden "AppUser" kadar basit bir şey bile yeterli olacaktır.

7

Kabul edilen bu cevap daha çok bir yan yorumdur ve soruyu cevaplamaz.

— Viliami

1824

Aynı sorum vardı ve burada tüm cevapları okuduktan sonra kesinlikle SINGULAR ile kalmak, nedenleri:

Sebep 1 (Kavram). "AppleBag" gibi elma içeren bir çanta düşünebilirsiniz, 0, 1 veya bir milyon elma içermesi önemli değil, her zaman aynı çanta. Tablolar sadece kaplar, tablo adı ne kadar veri içerdiğini değil, içerdiği şeyi tanımlamalıdır. Ek olarak, çoğul kavram daha çok bir konuşma dili ile ilgilidir (aslında bir veya daha fazla olup olmadığını belirlemek için).

Sebep 2 . (Kolaylık). tekil isimlerle çoğalmaktan daha kolaydır. Nesneler düzensiz çoğullara sahip olabilir veya hiç çoğul olmayabilir, ancak her zaman tekil olanlara sahip olacaktır (Haberler gibi birkaç istisna dışında).

Müşteri
Sipariş
kullanıcı
durum
Haberler

Sebep 3 . Estetik ve Düzen. Özellikle ana ayrıntı senaryolarında, bu daha iyi okunur, ada göre daha iyi hizalanır ve daha mantıklı bir sıraya sahiptir (önce Master, Ayrıntı ikinci):

1.Order
2.OrderDetail

Nazaran:

1.OrderDetails
2.Orders

Sebep 4 (Basitlik). Tablo Adları, Birincil Anahtarlar, İlişkiler, Varlık Sınıfları ... Bir araya getirmek, iki (tekil sınıf, çoğul tablo, tekil alan, tekil çoğul ana-ayrıntı) yerine tek bir adın (tekil) farkında olmak daha iyidir. .)

Customer
Customer.CustomerID
CustomerAddress
public Class Customer {...}
SELECT FROM Customer WHERE CustomerID = 100

"Müşteri" ile uğraştığınızı öğrendikten sonra, tüm veritabanı etkileşimi ihtiyaçlarınız için aynı kelimeyi kullanacağınızdan emin olabilirsiniz.

Sebep 5 . (Küreselleşme). Dünya küçülüyor, farklı milletlerden oluşan bir ekibe sahip olabilirsiniz, herkesin ana dili İngilizce değil. Anadili İngilizce olmayan bir programcının "Havuz" u "Havuzlar" veya "Durumlar" yerine "Durum" olarak düşünmesi daha kolay olacaktır. Tekil isimlere sahip olmak, yazım hatalarının neden olduğu daha az hataya yol açabilir, "Çocuk mu Çocuk mu?"

Sebep 6 . (Neden olmasın?). Hatta yazma zamanından tasarruf edebilir, disk alanından tasarruf edebilir ve hatta bilgisayarınızın klavyesini daha uzun süre dayanabilir!

SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

3 harf, 3 bayt, 3 ekstra klavye isabeti kaydettiniz :)

Ve son olarak, aşağıdaki gibi ayrılmış isimlerle uğraşanları adlandırabilirsiniz:

Kullanıcı> LoginUser, AppUser, SystemUser, CMSUser, ...

Veya rezil köşeli parantez kullanın [Kullanıcı]

— Nestor
kaynak

625

Bir çorap çekmecesine bir etiket koyarsanız buna "Çoraplar" diyeceksiniz.

— Chris Ward

73

Definetelly. Herkes için ve herkes için çalışan bir standart elde etmek zor, önemli olan sizin için çalışıyor. Bu benim için çalışıyor ve burada nedenini açıkladım, ama yine, bu benim için ve çok uygun buluyorum.

— Nestor

451

Daha büyük soru Chris, neden bir çorap çekmecesini adlandırırken veritabanı adlandırma kurallarını takip edesiniz?

— Kyle Clegg

83

Bu cevabın daha fazla övgüye ihtiyacı var. Tekil isimleri neden tercih ettiğime uyguladığım birçok pratik nedeni tartışıyor. Kümelere referans olarak uygun dil hakkındaki alternatif tartışmalar sadece felsefi ve gerçek noktayı gizliyor. Tekil daha iyi çalışır.

— Jason

298

Evde bir "Sock" çekmecem var, "Socks" çekmecem değil. Bir veritabanı olsaydı, buna "Çorap" tablosu derdim.

— jlembke

260

Gelecekte Nesne İlişkisel Haritalama araçlarını veya iradesini kullanırsanız Singular'ı öneririm .

LLBLGen gibi bazı araçlar, tablo adını değiştirmeden Kullanıcılar gibi çoğul adları otomatik olarak Kullanıcıya Kullanıcı olarak düzeltebilir. Bu neden önemli? Çünkü eşlendiğinde Users.Name yerine User.Name gibi görünmesini istersiniz veya kodda kafa karıştırıcı olan tblUsers.strName adlı eski veritabanları tablolarımdan daha kötüsüdür.

Yeni temel kuralım, bir nesneye dönüştürüldükten sonra nasıl görüneceğini yargılamak.

kullandığım yeni adlandırmaya uymayan bulduğum bir tablo UsersInRoles. Ancak her zaman birkaç istisna olacak ve bu durumda bile UsersInRoles.Username gibi iyi görünüyor.

— Brian Boatright
kaynak

48

Oy verdim ve size nedenini anlatacağım, çünkü katılmıyorum. ORM doğası gereği haritalama ile ilgilidir. Kullandığım her ORM aracı, varlığın adından farklı olduğunda varlık için kullanılacak tablo adını belirtmeyi destekler. Bu önemlidir, çünkü ilişkisel veritabanlarına eşlememizin tüm nedeni, nesne modelimizden farklı şekillerde geçici sorguları ve raporları kolayca yapabilmemizdir. Aksi takdirde, şimdiye kadar sadece nesne / belge veritabanlarını kullanıyorduk.

— joshperry

25

ORM, eşlendikleri nesnelerin adlarını dikte etmemelidir. ORM'nin noktası, bu esnekliği veren nesnenin bir soyutlamasıdır.

— barrypicker

19

Dünyamda, bu örneğin sonunda bir s olup olmadığını merak etmek için zaman kaybetmemek için tüm proje boyunca tutarlı isimler kullanmaya çalışıyorum. Bir ORM olması olabilir bağımsız doesnt adlandırmak ve olmayacak bunu yapmanız, diğer geliştiricilerin yardımcı oluyor anlamına gelir.

— John Nicholas

2

Bazı ORM (birçok programlama aracı gibi), yapılandırmasız uygulamalar üreten varsayılan davranışa sahiptir ... PRODUCTIVITY satış noktasıyla. Dolayısıyla, açık bir eşleme olmadan bir Employee sınıfı oluşturmak, varsayılan olarak bir Employee tablosu oluşturacaktır

— user919426

1

@barrypicker. Çoğul isimler ORM kodunda sadece aptal görünmez. Çoğullar, özellikle benzersiz bir özniteliğe başvururken SQL'de de kötü görünür. Kullanıcılardan select user.id'i kim yazmamış? Ya da belki ... kullanıcılardan thingy.user_id = user.id ... 'e katılmayı bıraktı?

— Samuel Danielson

219

İngilizce'de tekil olan akılsız ismi kullanmayı tercih ederim .

Tablo adının sayısını etkilemek, ortografik sorunlara neden olur (diğer yanıtların çoğunun gösterdiği gibi), ancak bunu seçmek, genellikle tablolar birden çok satır içerdiğinden, anlamsal olarak deliklerle doludur. Bu, duruma göre isimleri etkileyen bir dil düşünürsek daha açıktır (çoğu gibi):

Genellikle satırlarla bir şeyler yaptığımız için, adı neden suçlayıcı davaya eklemiyorsunuz? Okuduğumuzdan daha fazla yazdığımız bir masamız varsa, adı neden datif yazmıyorsunuz? Bu bir masadır ait ilgi hâli neden kullanmaz, bir şey? Bunu yapmayız, çünkü tablo durumu veya kullanımından bağımsız olarak var olan soyut bir kap olarak tanımlanır. İsmi kesin ve mutlak anlamsal bir sebep olmadan etkilemek gevezeliktir.

Enfekte olmayan ismi kullanmak basit, mantıklı, düzenli ve dilden bağımsızdır.

— Ian Mackinnon
kaynak

37

Muhtemelen bu konuyla ilgili şimdiye kadar gördüğüm en mantıklı argüman ve o zaman Latince'de geçirdiğim için beni mutlu ediyor. Kesinlikle +1.

52

Kelime dağarcığımı açıkça artırmam gerekiyor.

— TJ Biddle

19

+1 Bakın, bunlar İnternet'in daha fazla ihtiyacı olan cevaplardır. Mükemmel mantığı uygulamak için zengin kelime dağarcığını kullanarak kusursuz kanıtlar.

— OCDev

8

Latince programlama yaptığımda bunu not edeceğim. Bu arada kullanıcılar kullanıcı tablosuna, müşteriler ise müşteri tablosuna girecek.

— Caltor

8

İkna olmuş - etkilenmemiş. Bu kadar zaman sonra görmek ilginç, popüler seçeneklerdir "tekil" ve "çoğul" hem yanlış!

— Stuart

126

Tabloların tekil isimlere sahip olması için hangi sözleşme gerekir? Her zaman çoğul isimler olduğunu düşünürdüm.

Kullanıcılar tablosuna bir kullanıcı eklenir.

Bu site kabul eder:
http://vyaskn.tripod.com/object_naming.htm#Tables

Bu site aynı fikirde değil (ancak buna katılmıyorum):
http://justinsomnia.org/writings/naming_conventions.html

Diğerlerinin de belirttiği gibi: bunlar sadece yönergelerdir. Sizin ve şirketiniz / projeniz için uygun bir sözleşme seçin ve buna uyun. Tekil ve çoğul veya bazen kısaltılmış kelimeler arasında geçiş yapmak bazen bazen çok daha ağırlaştırıcıdır.

— Michael Haren
kaynak

46

Set teorisini tablolara uygularken, setteki herhangi bir örnek setin temsilcisidir, bu yüzden Apple bir Apple setidir, sette kaç elmanın olduğuna dair agnostiktir - birçok örneğe sahip bir Apple'dır. Bir elma torbası, birçok elma içerdiğinde 'torba' olmaz.

— ProfK

89

İçinde 5 elma bulunan bir çantanız varsa ne olur? Buna elma torbası mı diyorsunuz? ya da bir torba elma?

— Christopher Mahan

26

Bence teori bu sete Elma denir. Tek bir elma hala "bir Elma Seti" dir - yine de, tek bir örneği olan bir kümedir. Birden çok elma da bir "Elma Seti" dir.

— Mark Brackett

26

@Christopher, çantanın kuru üzüm elmaları ve sadece elmaları tutmaksa, o zaman 1 elma, 100 elma veya elma içermese de bir "elma çantası" dır.

— Ian Mackinnon

14

@ Ian: Bunun nedeni, bir tablonun genel olması ve bir nakliye konteyneriyle karşılaştırılabilmesidir (elma kasalarından Harley Davidson motosiklet kasalarına kadar neredeyse her şeyi içerebilir). Diyorsun: Portakallı bir kargo konteyneri değil, portakallı bir kargo konteyneri. Diyorsun ki: araba parçaları kargo konteyneri değil, araba parçaları kargo konteyneri. Elma adları gibi yalnızca belirli bir veri türünü tutmak için özel bir veri yapısı yaptıysanız ve buna "kungabogo" adını verdiyseniz, bir elma kungaboko'nuz olabilir. Ne düşündüğünüzü biliyorum, ama önce top kesesini düşünün ve anlamdaki farkı anlayın.

— Christopher Mahan

79

Basit bir örnek olarak buna ne dersiniz:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

İkincisi SQL, öncekinden daha garip geliyor.

Tekil oy kullanıyorum .

— james
kaynak

50

Bu örnekte evet, ama pratik sql'de asla bu şekilde yazılmayacaktı. Bir tablo takma adınız olurdu, bu yüzden daha çok olurduSELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'

— Michael Haren

+1, (bir yıl sonra) Tekil olanın nasıl anlamlı olduğuna dair TERRIFIC bir örnek verdiniz. Bu biraz dini bir tartışma. Birkaç yıl önce bir veri mimarı tarafından yıllar boyu tekil olana dönüştüm ve bana doğru geldi (geçiş yapmam için çok ikna etmeyi gerektirdikten sonra).

— Chris Adragna

24

Bence sql daha çoğul gibi geliyor. Her sütun için tablo adınız olmaz, neden bu kadar çok yazmayı seviyorsunuz? Adı, Müşterileri Adresini NEREDEN SEÇİN> Ad> "def" Def'den sonra adın daha büyük olduğu müşteri havuzundan seçim yapıyorsun.

— Jamiegs

6

Bu sorunu çözmek için bir diğer ad / AS kullanmaya ne dersiniz? Müşteri.Name, Müşteri.NEREDEN Müşteri NEREDEN Müşteri Olarak Adres.Name> "def"

— James Hughes

1

İkincisi daha iyi, tekil sesler İngilizce konuşamayan biri gibi geliyor.

— HLGEM

61

Bir Varlık İlişkisi Şemasında, varlığın, tekil bir sınıf adına benzer şekilde tekil bir adla yansıtılması gerektiğine inanıyorum. Bir kez başlatıldığında, ad örneğini yansıtır. Bu nedenle veritabanlarında, tablo haline getirildiğinde varlık (varlık veya kayıt koleksiyonu) çoğul olur. Varlık, Kullanıcı tablo Kullanıcılar yapılır. Belki Kullanıcı isminin Çalışan için geliştirilebileceğini veya senaryonuz için daha uygulanabilir bir şey öneren diğer kullanıcılarla aynı fikirdeyim.

Bu, daha sonra bir kayıt grubundan seçim yaptığınız ve tablo adı tekil ise, iyi okumadığı için bir SQL ifadesinde daha anlamlı olur.

— Adam Carr
kaynak

3

Özellikle SQL deyimi yorumu gibi. Burada tekil kullanmak okuyucuya sezgisel gelmez.

— hochl

2

ERD hakkında mükemmel bir nokta. Bu yüzden, dünyayı DBA gözleriyle gören birine tekil adlandırma mantıklı geliyor. Sizin de belirttiğiniz gibi, bir varlık ile bunların bir koleksiyonu arasındaki farkı alamadıklarından şüpheleniyorum.

— William T. Mallard

1

Bir tablo bir kayıt koleksiyonu değildir; tablo, bir kaydın neye benzediğinin bir tanımıdır. Bu, çoğul / tekil halkın sahip olduğu kopukluktur.

— zengin hatırlatıcı

SQL deyim yorumuna katılmıyorum. Users.Id

— hashtable

1

Bir old_lady'de çok sayıda kedi var VEYA old_ladies'de kediler var. ERD'lerin çoğul olarak daha güzel okuduklarını düşünüyorum. Ve varlıkların tablosu, tabloların birçok varlığı var, bu yüzden yine çoğul seslerin güzel olduğunu düşünüyorum.

— user3121518

39

Ben sopa ile Tekil tablo adları için ve herhangi bir programlama varlık.

Sebep? İngilizcede fare - koyun ve koyun-koyun gibi düzensiz çoğulların olması . Sonra, bir koleksiyona ihtiyacım varsa , sadece fareler veya koyunlar kullanıyorum ve devam ediyorum .

Gerçekten çokluğun öne çıkmasına yardımcı olur ve şeylerin koleksiyonunun nasıl görüneceğini kolayca ve programlı olarak belirleyebilirim.

Yani benim kural şudur: her şey tekildir şeylerin her koleksiyon bir ile tekil olan s eklenir. ORM'lere de yardımcı olur.

— Paulo Freitas
kaynak

7

's' ile biten bir kelimeye ne dersiniz? 'Haberler' adında bir tablonuz varsa (örnek olarak), haberlerin derlemesine ne derdiniz? Newss? Yoksa tabloya Yeni mi derdiniz?

— Anthony

18

NewsItem tablosunu ve NewsItems koleksiyonunu çağırırım.

— Ash Machine

5

Tüm kodu yazım denetimi yapmanız gerekiyorsa, yoksa derlemeyecektir;)?

— Hamish Grubijan

2

ORM, eşlendikleri nesnelerin adlarını dikte etmemelidir. ORM'nin noktası, bu esnekliği veren nesnenin bir soyutlamasıdır.

— barrypicker

16

@HamishGrubijan kodunuzu yazmak için Word'ü kullanmayı bırakın! ;)

— Valentino Vranken

36

IMHO, tablo adları Müşteriler gibi çoğul olmalıdır .

Sınıf adları , Müşteriler tablosundaki bir satırla eşleşiyorsa, Müşteri gibi tekil olmalıdır .

— Gülzar Nazim
kaynak

33

Tekil. En mantıklı olan hiçbir argüman almıyorum - her insan kendi tercihinin en mantıklı olduğunu düşünüyor. Ne yaparsanız yapın bir karmaşa, sadece bir kongre seçin ve ona sadık kalın. Oldukça düzensiz dilbilgisi ve anlambilim (normal konuşma ve yazı dili) olan bir dili çok özel anlambilime sahip oldukça düzenli (SQL) dilbilgisi ile eşleştirmeye çalışıyoruz.

Benim asıl argümanım tabloları küme olarak değil ilişkiler olarak düşünmem.

Böylece AppUserilişki hangi varlıkların olduğunu söyler AppUsers.

AppUserGroupİlişki varlıklardır hangi söylüyorAppUserGroups

AppUser_AppUserGroupİlişki nasıl söyler AppUsersve AppUserGroupsilişkilidir.

AppUserGroup_AppUserGroupİlişki nasıl söyler AppUserGroupsve AppUserGroups(gruplar yani gruplar üyesi) ilişkilidir.

Başka bir deyişle, varlıkları ve bunların nasıl ilişkili olduklarını düşündüğümde, tekil olarak ilişkileri düşünüyorum, ama elbette, koleksiyonlardaki veya kümelerdeki varlıkları düşündüğümde, koleksiyonlar veya kümeler çoğuldur.

Benim kodumda, ve veritabanı şemasında tekil kullanıyorum. Metinsel açıklamalarda, daha fazla okunabilirlik için çoğul kullanıyorum - sonra tablo / ilişki adını çoğuldan ayırmak için yazı tipleri vb. Kullanıyorum.

Bunu dağınık, ama sistematik olarak düşünmeyi seviyorum - ve bu şekilde ifade etmek istediğim ilişki için her zaman sistematik olarak oluşturulmuş bir isim var, ki bu benim için çok önemli.

— Jacob Lorensen
kaynak

1

kesinlikle. birçok kişinin burada farkında olmadığı ana şey, isimlendirdikleri şeydir ... tablodaki kayıtlar kümesine değil, bir ilişkiye (tablodaki tek bir kayıt) isim veriyorsunuz.

— Alexandre Martini

3

Daha fazla anlaşamadım. 'Adın' J% 'gibi olduğu Kullanıcılar'dan * seçin * çünkü adın' J 'ile başladığı tüm kullanıcıları seçiyorum. Argümanınız '... burada Kullanıcı.Adı gibi ...' yazmak istediğinizse, sadece bir takma ad kullanın. Aynı sebeple 'Bana tüm çoraplardan bir çift ver' diyorum.

— Mark A. Donohoe

Bu özel olsaydım tablo adım sock_pair olurdu

— Manuel Hernandez

@AlexandreMartini Kesinlikle. Tablodaki tek ilişkiyi "ilişki" olarak adlandıran bazı insanlar gibi .

— Nuno André

31

Ayrıca çoğullarla da giderdim ve yukarıda belirtilen Kullanıcılar ikilemi ile köşeli parantez yaklaşımını uyguluyoruz.

Bunu hem veritabanı mimarisi hem de uygulama mimarisi arasında tekdüzelik sağlamak için yapıyoruz, bunun altında Kullanıcılar tablosunun bir kod yapay yapısındaki Kullanıcılar koleksiyonu kadar Kullanıcı nesnelerinin bir koleksiyon olduğu kadar Kullanıcı değerlerinin bir toplamı olduğu da anlaşılmaktadır .

Veri ekibimizin ve geliştiricilerimizin aynı kavramsal dili konuşması (her zaman aynı nesne adları olmasa da), aralarında fikir aktarılmasını kolaylaştırır.

— Paulo Freitas
kaynak

8

Katılıyorum .. neden kod ve depolama arasındaki tutarsızlık? Asla kodunda "Kullanıcı" kullanıcı nesneleri koleksiyonu adlandırmak istiyorum ... öyleyse neden bir tablo çağırmak? Hiç bir anlamı yok. Yukarıdaki argümanları okuduğumda, onlar tabloya değil, varlığa odaklanıyorlar ... tablodaki whats arasında zihnimdeki tablodan farklı bir ayrım var.

— Jason

companiesDiğer tabloların çağrıldığı bir başvuru alanı gibi bir tablo adıyla nasıl başa çıkıyorsunuz company_id? Düzgün yazılmış olsa da, tablo adlandırma kuralları konusunda seçici olanlar için tutarsız görünüyor.

— Jake Wilson

1

Tekil olduğunu hatırlayarak companiesolduğunu companyve bu kimliği tekil bir öğeye bir referans olduğunu. Bizi İngilizce rahatsız eden koddan daha fazla rahatsız etmemelidir.

— David

22

Ben şahsen bir kümeyi temsil etmek için çoğul isimleri kullanmayı tercih ediyorum, bu sadece ilişkisel zihnime daha iyi "geliyor".

Şu anda şirketim için bir veri modeli tanımlamak için tekil isimler kullanıyorum, çünkü çalışan insanların çoğu onunla daha rahat hissediyor. Bazen kişisel tercihlerinizi uygulamak yerine hayatı herkese kolaylaştırmanız gerekir. (tabloları adlandırmak için "en iyi uygulama" ne olması gerektiği hakkında bir onay almak için bu iş parçacığı sonunda sona erdi)

Bu konudaki tüm tartışmaları okuduktan sonra bir sonuca ulaştım:

Herkesin en sevdiği lezzet ne olursa olsun, ballı kreplerimi seviyorum. Ama diğer insanlar için yemek pişiriyorsam, onlara sevdikleri bir şey sunmaya çalışacağım.

— birisi
kaynak

İlişkili model dünyasında, özellikle nesneler arasındaki ilişkiyi açıkladığınızda, bu tür bir konvansiyonu kullanmak akıllıca değildir, örn. "Her Takımın sadece bir Ana Antrenör ve birçok ikincil Koç olabilir": SecondaryCoach

— gör noonex

16

Tekil. Bir grup kullanıcı satır temsil nesneleri 'kullanıcılar' içeren bir dizi çağırır, ancak tablo 'kullanıcı tablosu'. Tabloyu içerdiği satır kümesinden başka bir şey olarak düşünmek yanlıştır, IMO; tablo meta verilerdir ve satır kümesi tabloya hiyerarşik olarak eklenir, tablonun kendisi değildir.

Elbette ORM'leri her zaman kullanıyorum ve çoğul tablo adları ile yazılmış ORM kodunun aptalca görünmesine yardımcı oluyor.

— kaos
kaynak

Her biri için, sanırım. İlişkisel veritabanı tablosu, tanım gereği bir başlıktır (yani, öznitelikleri adlandıran meta veriler) ve başlıkla eşleşen bir grup kümedir. Diğer veriler gruplara odaklanırken meta verilere odaklanabilirsiniz. :-)

— Bill Karwin

Hey, User_Table sevdiğim bir isim! :)

— Camilo Martin

3

ORM, eşlendikleri nesnelerin adlarını dikte etmemelidir. ORM'nin noktası, bu esnekliği veren nesnenin bir soyutlamasıdır.

— barrypicker

1

Ben bu şekilde bakıyorum .. Eğer kod bir şey bir dizi / liste / sözlük oluşturursanız, benim bahis onu tutar ne varsa çoğul adı ile adlandırma. Veritabanınızı özetlemek için bir ORM kullanıyorsanız, tablolar bir çeşit koleksiyonla temsil edilir, o zaman neden onlara farklı davranıyorsunuz? Tekil adları kullanmak kulağa hoş gelebilir, ancak her zaman bir tablonun aynı şeylerin çoğunu tuttuğu içgüdünüzle savaşıyorsunuz, tıpkı koddaki bir koleksiyon gibi. Neden tutarsızlık?

— Jason

@Jason: 1): karşılaştırmak ve bunlar okuma biçimini kontrast Lütfen $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something).

— kaos

16

Aslında her zaman çoğul tablo isimlerini kullanmanın popüler bir kural olduğunu düşündüm. Bu noktaya kadar hep çoğul kullandım.

Tekil tablo isimleri için argümanı anlayabiliyorum, ama bana göre çoğul daha anlamlı. Bir tablo adı genellikle tablonun içeriğini içerir. Normalleştirilmiş bir veritabanında, her tablo belirli veri kümeleri içerir. Her satır bir varlıktır ve tablo birçok varlık içerir. Böylece tablo adı için çoğul biçim.

Bir araba tablosunun adı arabalar olur ve her sıra bir arabadır. Tablonun alanla birlikte bir table.fieldşekilde belirtilmesinin en iyi yöntem olduğunu ve tekil tablo adlarına sahip olmanın daha okunabilir olduğunu kabul edeceğim . Bununla birlikte, aşağıdaki iki örnekte, ilk daha mantıklıdır:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

Dürüst olmak gerekirse, konuyla ilgili konumumu yeniden düşüneceğim ve geliştirdiğim kuruluş tarafından kullanılan gerçek sözleşmelere güveneceğim. Ancak, kişisel sözleşmelerim için, çoğul tablo isimlerine sadık kalacağım. Benim için daha mantıklı.

— Azgın
kaynak

9

RoR'daki sözleşme de öyle değil mi? Tablolar ve ORM sınıfları için tekil isimler? Bana çok mantıklı geliyor. Tablo "arabalar" olarak adlandırılır, çünkü "araba" nın birçok örneği vardır ve bir arabanın bir örneğini tutacağı için sınıf "Araba" olarak adlandırılır!

— Sap

@Sap Cümlenizin ikinci kısmının küçük bir düzeltmesi - "Araba" sınıfı, gerçek hayattaki bir Arabayı temsil eden Özet DataType'tır. Bir örneği veya katları tutup tutmayacağı, nasıl kullanıldığına bağlıdır.

— 16:15

yüzleşelim, masa cartek bir arabanın yapısının bir tanımıdır. Tablonun yapısına bakarsanız, temel olarak "id int, renk dizesi vb." Tükürür: yabancı anahtarla bir tablonuz olduğunu car_vendor(ya da çoğul versiyonunuz için cars_vendor) varsa cars_id? bu aptal bok nedir? öyle car_id düşünmeme yapmaya gerek yok. Tekil benim tarafımdan şiddetle tercih ediliyor

— Toskan

4

Bu cevabı gerçekten çok beğendim! Açıklamama izin ver. Koleksiyon ise carve her şeyi istediğiniz carolduğu bluesonucu gibi bir şey olmalıdır tire, mirror, engine. Ve sonra kafa karıştırıcı oluyor çünkü tüm sonuçlar partsbir car. Tablo adı olmalıdır Yani carparts(veya car_parts, CarPartsne gibi)

— arnoudhgz

Tekil tablo adlarını uygulayan herhangi bir veritabanı tasarımcısı, temelde gelecekte bu veritabanıyla temasa geçebilecek herhangi bir Ruby on Rails uygulama geliştiricisine karşı savaş ilan eder. Rail'in sınıflar için tekil kelimeler ve tablolar için çoğullaştırılmış isimler üzerindeki katı ısrarı, Ruby'nin ekosistemindeki birçok mücevherde çok güçlü bir davranış sağlar. Yani tekil sesleri daha iyi görünseniz bile, uyumluluk uğruna çoğul kalmanız gerekir. Bunun diğer Nesne İlişkisel Haritacıları için de geçerli olduğunu düşünüyorum.

— Kelsey Hannan

15

Çoğul tablo adlarını sevmiyorum çünkü İngilizce'deki bazı isimler sayılabilir (su, çorba, nakit) veya sayılabilir yaptığınızda anlam değişiklikleri (tavuk vs tavuk; et vs kuş). Ayrıca tablo adı veya sütun adı için kısaltmalar kullanmayı sevmiyorum çünkü bunu yapmak zaten dik öğrenme eğrisine ekstra eğim ekliyor.

İronik olarak, hale getirebileceğini Userbir istisna ve diyoruz Usersçünkü KULLANICI (Transac-SQL) Ben de mecbur yoksa tablolar etrafında parantez kullanarak sevmiyorum çünkü.

Ayrıca tüm kimlik sütunlarını Id, değil ChickenIdveya ChickensId(birden çok adam bu konuda ne yapar?) Olarak adlandırmak istiyorum.

Tüm bunlar, veritabanı sistemlerine uygun bir saygım olmadığı için, Java'nın alışkanlık ve tembelliği gibi OO adlandırma sözleşmelerinden sadece bir numara verdim . Keşke karmaşık SQL için daha iyi IDE desteği olsaydı.

— Eugene Yokota
kaynak

8

Bize çoğul çocuklar ya sizin gibi 'id' sütununu 'id' ya da 'singular_id' olarak adlandırırlar. Tabloların çoğul olması gerektiğine inanıyorum (bunları diziler gibi düşünün), ancak sütun adları tekil olmalıdır (tek bir öğenin özellikleri).

— mpen

tablo adları için plu_ral / PluRal, birincil anahtarlar için singular_id / singularId.

— hochl

14

Benzer standartlar kullanıyoruz, komut dosyaları için [] adlar etrafında talep ettiğimizde ve uygun olduğunda şema niteleyicileri - öncelikle SQL sözdizimi tarafından bahislerinizi gelecekteki ad kapmalarına karşı korur.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Bu, geçmişte ruhlarımızı kurtardı - bazı veritabanı sistemlerimiz, SQL 6.0'dan SQL 2005'e kadar 10 yıldan fazla bir süre çalıştı - amaçlanan ömürlerinin çok ötesinde.

— stephbu
kaynak

Ritüelist kendi kendini kırbaçlama gibi görünüyor. Henüz böyle bir isim yakalandı mı?

— Kjetil

13

Tablolar: çoğul

Birden çok kullanıcı, kullanıcı tablosunda listelenir.

Modelleri: singular

Kullanıcılar tablosundan tek bir kullanıcı seçilebilir.

Kontrolörler: çoğul

http://myapp.com/users birden fazla kullanıcıyı listeler.

Zaten bunu benim almam.

— Andrew
kaynak

1

Benimkine daha yakın, ancak benimki, tablonun birden fazla kullanıcının depolanmasının aslında rastlantısal olması ve herhangi bir tekil kullanıcının tablo tarafından temsil edilmesi veya daha ziyade bir Kullanıcı varlığını temsil eden bir grup küme olan ilişkidir.

— ProfK

Sanırım buna katılıyorum. Beni şaşırtan tek şey modeller neden tekil olmalı? Yalnızca model yalnızca tek bir Kullanıcı ile ilgiliyse. Ben tüm kullanıcıları almak için db sorgulama olsaydı o zaman model erişmek gerekir? Tekil bir örneğin tüm kayıtları getirmesi mantıklı değil, örnek: $ user-> get_all () // bir anlam ifade etmiyor

— PM7Temp

12

CASE sözdizimini kullanarak ER diyagramlarımı okumayı kolaylaştırdığı için tekil tablo adlarının hayranıyım, ancak bu yanıtları okuyarak hiç bu kadar iyi yakalanmadığı hissini alıyorum? Ben şahsen seviyorum. Tekil tablo adları kullandığınızda, ilişkilerinize eylem fiilleri eklediğinizde ve her ilişki için iyi cümleler oluşturduğunuzda modellerinizin ne kadar okunabilir olabileceğine dair örneklere iyi bir genel bakış vardır. 20 tablo veritabanı için biraz fazlalık var, ancak yüzlerce tablo ve karmaşık bir tasarıma sahip bir DB'niz varsa, geliştiricileriniz iyi bir okunabilir diyagram olmadan nasıl anlayacaklar?

http://www.aisintl.com/case/method.html

Tablo ve görünümlerin öneklerine gelince bu uygulamadan kesinlikle nefret ediyorum. Muhtemelen kötü bilgi vermeden önce bir kişiye hiçbir bilgi vermeyin. Nesneler için bir db tarama herkes kolayca bir görünümden bir tablo söyleyebilir, ancak tblUsers adlı bir tablo varsa, nedense iki kod halinde gelecekte yeniden yapılandırmak karar, bir görünüm ile eski kodu kırmak için onları birleştiren bir görünüm Şimdi tblUsers adlı bir görünüm var. Bu noktada iki cazip seçenekle kaldım, bazı geliştiricilerin kafasını karıştırabilecek bir tbl önekiyle adlandırılmış bir görünüm bırakın veya yeni yapımı veya isim viewUsers'ımı referans almak için yeniden yazılacak orta katman veya uygulama zorlayın. Bu IMHO görüşlerinin değerinin büyük bir kısmını yok sayar.

— Shane Delmore
kaynak

1

Nesne adlarını 'tür' niteleyicisi ile önek olarak gösteren tuzağa iyi bir örnek!

— Kenny Evitt

12

Sistem tables/viewssunucusunun kendisi ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, vb) neredeyse her zaman çoğul vardır. Tutarlılık uğruna onların peşinden giderdim sanırım.

— Michel
kaynak

Microsoft ilk olarak ticari nedenlerle (ve genellikle etik dışı nedenlerden dolayı), mantıksal nedenlerden sonradır. Onları takip etmemin tek sebebi onların büyük goril olması ve diğer herkesin bu şekilde gitmesi. Bir seçeneğim olduğunda, diğer yolu seçerim.

— Bruce Patin

1

information_schemaSQL standardı olan ISO / IEC 9075-11'in bir parçası olduğu belirtilmelidir . Ve evet, çoğul tablolar / görünüm adları kullanır.

— Paulo Freitas

10

MS SQL Server'sSistem tablolarına bakarsak, Microsoft tarafından atanan adları içindedir plural.

Oracle'ın sistem tabloları adlandırılmıştır singular. Her ne kadar birkaçı çoğul olsa da. Oracle, kullanıcı tanımlı tablo adları için çoğul olmasını önerir. Bu, bir şeyi tavsiye etmeleri ve bir diğerini takip etmeleri pek mantıklı değil. Bu iki yazılım devindeki mimarların tablolarını farklı kurallar kullanarak isimlendirmeleri de pek mantıklı değil ... Sonuçta, bu adamlar nelerdir?

Akademide hatırlıyorum, tavsiye tekildi.

Örneğin, dediğimizde:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

belki b / c her IDbiri belirli bir satırdan seçilir ...?

— Richard
kaynak

1

Microsoft ilk olarak ticari nedenlerle (ve genellikle etik dışı nedenlerden dolayı), mantıksal nedenlerden sonradır. Onları takip etmemin tek sebebi onların büyük goril olması ve diğer herkesin bu şekilde gitmesidir. Bir seçeneğim olduğunda, diğer yolu seçerim.

— Bruce Patin

İki şey. Birincisi, normalde tablo adlarını kullanmazsınız ve 'Bir şeylerin doğru olduğu OrderHeaders'tan tüm kimlikleri seçiyorsanız' ama siz bir tablo nedeniyle tablo adlarını kullanmak zorunda kaldığınızda 'OrderHROMers ID'yi seçin WHERE Reference =' ABC123 ' katılmak ya da her neyse, böyle bir takma ad kullanabilirsiniz ... 'OrderHeader.ID seçin OrderHeaders dan OrderHeader WHERE OrderHeader.Reference =' ABC123 '

— Mark A. Donohoe

9

Bu biraz gereksiz olabilir, ama temkinli olmanızı öneririm. Tabloları yeniden adlandırmanın kötü bir şey olması gerekmez, ancak standardizasyon sadece budur; bir standart - bu veritabanı zaten "standart", ancak kötü olabilir :) - Ben bu veritabanı zaten var ve muhtemelen 2 tablodan daha fazla oluşur göz önüne alındığında tutarlılık daha iyi bir hedef olarak öneririz.

Tüm veritabanını standardize edemediğiniz veya en azından bu amaçla çalışmayı planlayamadığınız sürece, tablo adlarının buzdağının sadece ucu olduğunu ve eldeki göreve konsantre olduğunu, kötü adlandırılmış nesnelerin acısını sürdüğünü sanıyorum. En iyi ilginiz -

Pratik tutarlılık bazen en iyi standarttır ... :)

my2cents ---

— Borzio
kaynak

9

Olası alternatifler:

SystemUser tablosunu yeniden adlandırın
Parantez kullanın
Çoğul tablo adlarını saklayın.

Parantez kullanan IMO teknik olarak en güvenli yaklaşımdır, ancak biraz hantaldır. IMO biri 6, diğeri yarım düzine diğeri ve çözümünüz kişisel / takım tercihinize bağlı.

— Dave Markle
kaynak

2

'Önek' fikrinizi seviyorum ama buna SystemUser diyorum.

— ProfK

9

Alım, kapsayıcınızı nasıl tanımladığınıza bağlı olarak anlambilimdedir. Örneğin, bir "elma torbası" veya sadece "elma" veya bir "elma torbası" veya "elma".

Örnek: "kolej" tablosu 0 veya daha fazla kolej içerebilir "kolejler" tablosu 0 veya daha fazla kolej içerebilir

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Benim sonucum, her ikisinin de iyi olduğu, ancak tablolara atıfta bulunurken (veya onunla etkileşime giren kişilerin) nasıl yaklaşacağınızı tanımlamanız gerekir; "balta tablosu" veya "xs tablosu"

— jleviaguirre
kaynak

8

Diğerlerinin burada belirttiği gibi, sözleşmeler kullanım kolaylığına ve okunabilirliğine katkıda bulunmak için bir araç olmalıdır. Geliştiricilere işkence etmek için bir zincir veya kulüp olarak değil.

Bununla birlikte, kişisel tercihim hem tablolar hem de sütunlar için tekil adlar kullanmaktır. Bu muhtemelen programlama geçmişimden geliyor. Sınıf isimleri bir tür koleksiyon olmadıkça genellikle tekildir. Aklımda, söz konusu tabloda bireysel kayıtları saklıyorum veya okuyorum, bu yüzden tekil bana mantıklı geliyor.

Bu uygulama aynı zamanda nesnelerim arasında çoktan çoğa ilişkiler depolayanlar için çoğul tablo adları ayırmamı sağlıyor.

Tablo ve sütun adlarımda da ayrılmış sözcüklerden kaçınmaya çalışıyorum. Burada söz konusu durumda, Kullanıcıların ayrılmış kullanıcı sözcüğünü kullanan bir tabloyu kapsülleme ihtiyacından kaçınmak için Kullanıcıların tekil kuralına karşı çıkmak daha mantıklıdır.

Birçokları bu karmaşayı eklediğine inanmasına rağmen, önekleri sınırlı bir şekilde (tablo adları için tbl, proc adları için sp_, vb.) Kullanmayı seviyorum. Ben de her zaman adı yazarken _ yerine + isabet sonunda CamelBack adları altçizgi tercih ederim. Diğerleri aynı fikirde değil.

Kural kurallarını adlandırmak için başka iyi bir bağlantı: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Sözleşmenizdeki en önemli faktörün, söz konusu veritabanı ile etkileşime giren insanlar için anlamlı olması olduğunu unutmayın. Adlandırma kuralları söz konusu olduğunda "Hepsini Yönetecek Tek Bir Halka" yoktur.

— Chris
kaynak

18

Macarca gösterimin dehşetini görmezden gelmek. Asla, asla, asla sp_ saklı yordamlar önünde kullanmayın çünkü MS-SQL bunu sistem saklı yordamlar için kullanır ve onlara özel davranır. Sp_ ana tabloda depolandığından, konumu niteleseniz bile MS-SQL her zaman önce görünür.

— Dieterich

8

Bence tekil olanı kullanmak üniversitede öğretildi. Ancak aynı zamanda , nesne yönelimli programlamanın aksine, bir tablonun kayıtlarının bir örneği olmadığını iddia edebilirsiniz .

Sanırım şu anda İngilizce'deki çoğul usulsüzlüklerden dolayı tekil lehine dönüyorum. Almanca'da tutarlı çoğul biçimlerden dolayı daha da kötüdür - bazen bir kelimenin çoğul olup olmadığını, önündeki makale (der / die / das) olmadan söyleyemezsiniz. Ve Çince dillerinde zaten çoğul biçimler yoktur.

— helloworlder
kaynak

Üniversitede masalar için çoğul öğretildim, burada bir kitabım var, 90'lardan DB yönetimi üçüncü baskısı, tablolar tekil; XML bölümü çoğul kullanırken, güncellenmiş bir kopya, 11e, tekil ve bazı kısaltılmış isimlerim var. \ n Ancak RDBMS bölümleri için gerçek içeriği kontrol ederseniz, bazı görüntülerde yüz gerdirme yapılmış olan kelimenin tam anlamıyla aynı metindir. \ n "Veri modelleme kontrol listesi" çoğul ve tekil hakkında hiçbir şey ifade etmez, sadece varlıkların tek bir nesneyle eşleşmesi gerekir, muhtemelen kitaplarda uygulamaya çalıştıkları şey budur.

— Marco

8

Bir zamanlar Kullanıcı tablosu için "Dostum" kullandım - aynı kısa karakter sayısı, anahtar kelimelerle çakışma yok, hala genel bir insana referans. Eğer kodu görebilecek havasız kafaları hakkında endişe olmasaydı, ben bu şekilde muhafaza olurdu.

— Bruce Patin
kaynak

8

Her zaman tekil kullandım çünkü bana öğretilen buydu. Ancak, son zamanlarda yeni bir şema oluştururken, uzun zamandır ilk kez, bu sözleşmeyi aktif olarak sürdürmeye karar verdim çünkü ... daha kısa. Her tablo adının sonuna bir 's' eklemek, her birinin önüne 'tbl_' eklemek kadar işe yaramaz görünüyor.

— Just Some Guy
kaynak

7

Bunun aptalca bir kongre olduğunu düşünürdüm. Çoğul tablo isimleri kullanıyorum.

(Bu politikanın arkasındaki rasyonel değerin, ORM kod üreticilerinin nesne ve toplama sınıfları üretmesini kolaylaştırması olduğuna inanıyorum, çünkü tekil bir addan çoğul bir ad üretmek tam tersi)

— James Curran
kaynak

11

Bu konvansiyon, ORM var olmadan uzun zaman önce ilişkisel teorinin bir parçası olmuştur.

— ProfK

1

ORM, eşlendikleri nesnelerin adlarını dikte etmemelidir. ORM'nin noktası, bu esnekliği veren nesnenin bir soyutlamasıdır.

— barrypicker

7

Tekil veya çoğul olsun, yalnızca aynı yazılan tablo adları için isimler kullanıyorum:

geyik balık geyik uçak size pantolon şort gözlük makas tür yavruları

— aynasız
kaynak

6

Bunu daha önceki cevapların hiçbirinde açıkça ifade edilmiş görmedim. Birçok programcının tablolarla çalışırken resmi bir tanımı yoktur. Genellikle "kayıtlar" veya "satırlar" açısından sezgisel olarak iletişim kurarız. Bununla birlikte, denormalize ilişkiler için bazı istisnalar dışında, tablolar genellikle anahtar olmayan nitelikler ve anahtar arasındaki ilişki belirli bir teorik işlevi oluşturacak şekilde tasarlanmıştır.

Bir fonksiyon, iki takım arasındaki çapraz ürünün bir alt kümesi olarak tanımlanabilir, burada anahtar takımının her bir elemanı haritalamada en fazla bir kez meydana gelir . Dolayısıyla bu açıdan ortaya çıkan terminoloji tekil olma eğilimindedir. İşlevleri içeren diğer matematiksel ve hesaplama teorilerinde (örneğin cebir ve lambda hesabı) aynı tekil (veya en azından çoğul olmayan) kuralı görür.

— jerseyboy
kaynak