IT-Swarm.Net

Dilemă de denumire a tabelului: nume singular și plural

Academia spune că numele tabelelor trebuie să fie singularul entității în care stochează atributele.

Îmi place orice T-SQL care necesită paranteze pătrate în jurul numelor, dar am redenumit o tabelă Users la singular, condamnându-i pentru totdeauna pe cei care folosesc tabelul, uneori, trebuie să folosească paranteze.

Sentimentul meu intestinal este că este mai corect să rămân cu singularul, dar senzația mea de intestin este și faptul că parantezele indică nedorite precum numele de coloane cu spații în ele etc.

Sa stau sau sa plec?

1332
ProfK

Alții au dat răspunsuri destul de bune în ceea ce privește „standardele”, dar am vrut doar să adaug acest lucru ... Este posibil ca „Utilizator” (sau „Utilizatori”) să nu fie de fapt o descriere completă a datelor păstrate în tabel. ? Nu că ar trebui să vă înnebuniți cu numele și specificul tabelelor, dar poate că ceva de genul „Widget_Users” (unde „Widget” este numele aplicației sau site-ului dvs. web) ar fi mai potrivit.

225
Tom H

Am avut aceeași întrebare și după ce am citit toate răspunsurile aici rămân cu SINGULAR motivele:

Motivul 1 (Concept). Vă puteți gândi la sacul care conține mere precum "AppleBag", nu contează dacă conține 0, 1 sau un milion de mere, este întotdeauna aceeași pungă. Tabelele sunt doar atât, containerele, numele tabelului trebuie să descrie ce conține, nu cât de multe date conține. În plus, conceptul plural este mai mult despre o limbă vorbită (de fapt, pentru a determina dacă există una sau mai multe).

Motivul 2. (Confort). este mai ușor să iasă cu nume singulare decât cu plural. Obiectele pot avea pluraluri neregulate sau deloc plural, dar vor avea întotdeauna unul singular (cu puține excepții, cum ar fi News).

  • Client
  • Ordin
  • Utilizator
  • Stare
  • Știri

Motivul. (Estetică și ordine). În special în scenariile de detaliu maestru, acest lucru citește mai bine, se aliniază mai bine după nume și are o ordine mai logică (Master primul, Detaliu al doilea):

  • 1.Order
  • 2.OrderDetail

Comparat cu:

  • 1.OrderDetails
  • 2.Orders

Motivul 4 (Simplitate). Pune toate laolaltă, Nume tabele, chei primare, relații, clase de entitate ... este mai bine să fii conștient de un singur nume (singular) în loc de două (clasă singulară, tabel plural, câmp singular, singular-detaliu maestru-detaliu .. .)

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

După ce știi că ai de-a face cu „Clientul”, poți fi sigur că vei folosi același cuvânt pentru toate nevoile de interacțiune a bazei de date.

Motivul 5. (Globalizare). Lumea este din ce în ce mai mică, este posibil să aveți o echipă de naționalități diferite, nu toată lumea are engleza ca limbă maternă. Ar fi mai ușor pentru un programator nativ din limba engleză să se gândească la „Repository” decât la „Repositories” sau „Statuses” în loc de „Status”. A avea nume singulare poate duce la mai puține erori cauzate de dactilografii, economisind timp prin faptul că nu trebuie să gândești „este vorba despre Copil sau Copii?”, Îmbunătățind astfel productivitatea.

Motivul 6. (De ce nu?). Vă poate economisi chiar timpul de scriere, vă poate economisi spațiu pe disc și chiar poate face ca tastatura computerului să dureze mai mult!

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

Ați salvat 3 litere, 3 octeți, 3 accesări suplimentare de la tastatură :)

Și în cele din urmă, le puteți numi pe cele care se confruntă cu nume rezervate precum:

  • User> LoginUser, AppUser, SystemUser, CMSUser, ...

Sau folosiți parantezele pătrate infame [Utilizator]

1618
Nestor

Dacă utilizați instrumente de mapare relațională de obiecte sau pe viitor, vă sugerez Singular.

Unele instrumente precum LLBLGen pot corecta în mod automat nume plural ca Utilizatori la Utilizator, fără a schimba numele tabelului în sine. De ce contează asta? Deoarece atunci când este mapat, doriți să arate ca User.Name în loc de Users.Name sau mai rău din unele tabele de baze de date vechi denumite tblUsers.strName, care este doar confuz în cod.

Noua mea regulă este de a judeca cum va arăta odată ce a fost convertită într-un obiect.

un tabel pe care l-am găsit care nu se potrivește cu noua denumire pe care o folosesc este UserInRoles. Dar întotdeauna vor exista acele câteva excepții și chiar în acest caz arată bine ca UserInRoles.Username.

250
Brian Boatright

Prefer să folosesc substantivul ninflected, care în engleză se întâmplă să fie singular.

Influențarea numărului numelui tabelei provoacă probleme ortografice (așa cum arată multe dintre celelalte răspunsuri), dar alegerea să facă acest lucru deoarece tabelele conțin de obicei mai multe rânduri este, de asemenea, semantic de găuri. Acest lucru este mai evident dacă luăm în considerare o limbă care reflectă substantivele bazate pe caz (așa cum o fac majoritatea):

Întrucât de obicei facem ceva cu rândurile, de ce să nu punem numele în cazul acuzativ? Dacă avem un tabel pe care scriem mai mult decât citim, de ce să nu introducem numele în dativ? Este un tabel din ceva, de ce să nu folosești genitivul? Nu am face acest lucru, deoarece tabelul este definit ca un container abstract care există indiferent de starea sau de utilizare. Influențarea substantivului fără un motiv semantic precis și absolut este păcălire.

Folosirea substantivului neinflamat este simplă, logică, regulată și independentă de limbă.

198
Ian Mackinnon

Ce convenție necesită ca tabelele să aibă nume singulare? Întotdeauna am crezut că este vorba de nume plural.

La tabelul Utilizatori este adăugat un utilizator.

Acest site este de acord:
http://vyaskn.tripod.com/object_naming.htm#Tables

Acest site nu este de acord (dar nu sunt de acord cu acesta):
http://justinsomnia.org/writings/naming_conventions.html


După cum au menționat alții: acestea sunt doar orientări. Alegeți o convenție care funcționează pentru dvs. și compania/proiectul dvs. și rămâneți cu ea. Comutarea între singular și plural sau uneori prescurtarea cuvintelor și alteori nu este mult mai agravantă.

124
Michael Haren

Ce zici de asta ca un exemplu simplu:

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

vs.

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

SQL din acesta din urmă sună mai ciudat decât primul.

Votez pentru singular.

69
james

Am convingerea fermă că într-o diagramă de relație de entitate, entitatea trebuie reflectată cu un nume singular, similar cu un nume de clasă fiind singular. Odată instanțiat, numele reflectă instanța sa. Deci, cu bazele de date, entitatea atunci când este făcută într-un tabel (o colecție de entități sau înregistrări) este plural. Entitate, Utilizator este făcut în tabel Utilizatori. Aș fi de acord cu alții care mi-au sugerat că numele de utilizator ar putea fi îmbunătățit pentru angajat sau ceva mai aplicabil scenariului dvs.

Acest lucru are apoi mai mult sens într-o declarație SQL, deoarece selectați dintr-un grup de înregistrări și dacă numele tabelului este singular, nu citește bine.

59
Adam Carr

Eu rămân cu singular pentru numele tabelelor și orice entitate de programare.

Motivul? Faptul că există pluraluri neregulate în engleză precum mouse ⇒ șoareci și sheep ⇒ sheep . Apoi, dacă am nevoie de o colecție , folosesc doar cămăși sau oi și mergeți mai departe.

Ajută cu adevărat pluralitatea să iasă în evidență și pot determina cu ușurință și programatic cum ar arăta colecția de lucruri.

Deci, regula mea este: totul este singular, fiecare colecție de lucruri este singulară cu un s anexat. Ajută și cu ORM-urile.

37
Ash Machine

Singular. Nu cumpăr niciun argument care să fie cel mai logic - fiecare persoană crede că preferințele sale sunt cele mai logice. Indiferent ce faceți este o încurcătură, alegeți doar o convenție și respectați-o. Încercăm să mapăm o limbă cu gramatică și semantică extrem de neregulate (limbă normală vorbită și scrisă) către o gramatică extrem de regulată (SQL) cu semantică foarte specifică.

Principalul meu argument este că nu consider tabelele ca un set, ci ca relații.

Deci, relația AppUser spune ce entități sunt AppUsers.

Relația AppUserGroup îmi spune ce entități sunt AppUserGroups

Relația AppUser_AppUserGroup îmi spune cum sunt înrudite AppUsers și AppUserGroups.

Relația AppUserGroup_AppUserGroup îmi spune cum AppUserGroups și AppUserGroups sunt legate (adică grupuri membre ale grupurilor).

Cu alte cuvinte, când mă gândesc la entități și la modul în care acestea sunt înrudite mă gândesc la relații în singular, dar, desigur, când mă gândesc la entitățile din colecții sau seturi, colecțiile sau seturile sunt plural.

În codul meu, apoi, și în schema bazei de date, folosesc singular. În descrieri textuale, sfârșesc folosind pluralul pentru o mai mare lizibilitate - apoi folosesc fonturi etc. pentru a distinge numele tabelului/relației de pluralul s.

Îmi place să cred că este dezordonat, dar sistematic - și în acest fel există întotdeauna un nume generat în mod sistematic pentru relația pe care doresc să o exprim, ceea ce pentru mine este foarte important.

31
Jacob Lorensen

IMHO, numele tabelelor trebuie să fie plural asemănătoare Clienți .

Numele clasei ar trebui să fie singulare ca Client dacă se asortează la un rând în Clienți masa.

29
Gulzar Nazim

De asemenea, aș merge cu pluraluri, și cu amintita Utilizatori dilemă, luăm abordarea de paranteză pătrată.

Facem acest lucru pentru a asigura uniformitatea atât asupra arhitecturii bazei de date, cât și a arhitecturii de aplicații, înțelegând că tabelul Utilizatori este o colecție de Utilizatorul valori la fel de mult ca o Colecția de utilizatori într-un artefact de cod este o colecție de Obiecte utilizator .

Având echipa noastră de date și dezvoltatorii noștri care vorbesc același limbaj conceptual (deși nu întotdeauna aceleași nume de obiect), ușurează transmiterea ideilor între ele.

28
Joseph Ferris

Eu personal prefer să folosesc nume plural pentru a reprezenta un set, doar „sună” mai bine în mintea mea relațională.

În acest moment, folosesc nume singulare pentru a defini un model de date pentru compania mea, deoarece majoritatea persoanelor care lucrează se simt mai confortabile cu aceasta. Uneori trebuie doar să ușurezi viața tuturor, în loc să-ți impui preferințele personale. (așa am ajuns în acest thread, pentru a obține o confirmare a ceea ce ar trebui să fie „cea mai bună practică” pentru tabelele de denumire)

După ce am citit toate argumentele din acest thread, am ajuns la o concluzie:

Îmi plac clătitele mele cu miere, indiferent de aroma preferată a fiecăruia. Dar dacă gătesc pentru alți oameni, voi încerca să le servesc ceva ce le place.

19
someone

Singular. Aș numi un tablou care conține o mulțime de obiecte de reprezentare a rândului utilizatorilor „utilizatori”, dar tabelul este „tabelul utilizatorului”. Gândirea tabelului ca fiind altceva decât setul de rânduri pe care îl conține este greșit, IMO; tabela este metadata, iar setul de rânduri este atașat ierarhic la tabel, nu este tabelul în sine.

Folosesc ORM-uri tot timpul, desigur, și ajută ca codul ORM scris cu nume de tabel plural să arate prost.

16
chaos

Rămânem standarde similare, când scriem cerințe [] în jurul numelor și, după caz, calificativele schemelor - în primul rând, vă protejează pariurile împotriva capturilor de nume viitoare prin sintaxa SQL.

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

Acest lucru ne-a salvat sufletele în trecut - unele dintre sistemele noastre de baze de date au rulat 10+ ani de la SQL 6.0 până la SQL 2005 - trecând de la planurile de viață prevăzute.

14
stephbu

Nu-mi plac numele de tabel plural, deoarece unele substantive din engleză nu sunt numărabile (apă, ciorbă, numerar) sau sensul se schimbă atunci când îl faci să fie numărabil (pui vs. un pui; carne vs pasăre). De asemenea, nu-mi place să folosesc prescurtări pentru numele tabelelor sau pentru numele coloanei, deoarece acest lucru adaugă o pantă suplimentară la curba de învățare deja abruptă.

În mod ironic, aș putea face ca User să fie o excepție și să o numesc Users din cauza SER (Transac-SQL) , deoarece nici mie nu îmi place să folosesc paranteze în jurul tabelelor, dacă nu trebuie.

De asemenea, îmi place să numesc toate coloanele ID ca Id, nu ChickenId sau ChickensId (ce fac tipii plural în acest sens?).

Toate acestea se datorează faptului că nu am respectul corespunzător pentru sistemele de baze de date, reaplic doar cunoștințe cu un singur truc din OO Convenții de denumire precum Java's din obișnuință și lenea . Mi-aș dori să existe mai mult suport [IDE pentru SQL complicat.

14
Eugene Yokota

Întotdeauna am crezut că este convenție populară folosirea numelor de tabel plural. Până în acest moment am folosit întotdeauna plural.

Pot înțelege argumentul pentru nume de tabel singulare, dar pentru mine plural are mai mult sens. Un nume de tabel descrie de obicei ce conține tabelul. Într-o bază de date normalizată, fiecare tabel conține seturi de date specifice. Fiecare rând este o entitate și tabelul conține multe entități. Astfel, forma de plural pentru numele tabelului.

Un tabel de mașini va avea numele mașini și fiecare rând este o mașină. Voi admite că specificarea tabelului împreună cu câmpul într-o manieră table.field este cea mai bună practică și că având nume de tabel singulare este mai lizibil. Cu toate acestea, în următoarele două exemple, primul are mai mult sens:

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

Sincer, voi regândi poziția mea în această privință și m-aș baza pe convențiile reale utilizate de organizația pentru care dezvolt. Cu toate acestea, cred că pentru convențiile mele personale, voi lipi cu nume de tabel plural. Pentru mine are mai mult sens.

13
Randy

Sunt un fan al numelor tabelelor singulare, întrucât fac diagramele mele ER folosind sintaxa CASE mai ușor de citit, dar citind aceste răspunsuri am senzația că nu a prins niciodată foarte bine? Eu personal îmi place. Există o imagine de ansamblu bună cu exemple despre cât de lizibile pot fi modelele dvs. atunci când utilizați nume de tabel singulare, adăugați verbe de acțiune la relațiile dvs. și formați propoziții bune pentru fiecare relație. Este totul un pic excesiv pentru o bază de date cu 20 de tabele, dar dacă aveți o DB cu sute de tabele și un design complex, cum vor înțelege dezvoltatorii dvs. vreodată fără o diagramă bună care poate fi citită?

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

În ceea ce privește tabelele și vizualizările de prefixare, urăsc absolut această practică. Nu dați unei informații deloc unei persoane înainte de a le oferi informații posibile. Oricine răsfoiește un db pentru obiecte poate spune cu ușurință o tabelă dintr-o vizualizare, dar dacă am o tabelă numită tblUsers, care, din anumite motive, decid să restructur în viitor în două tabele, în vederea unificării acestora pentru a nu împiedica codul vechi Acum am o vedere numită tblUsers. În acest moment, am rămas cu două opțiuni nerevazute, lăsați o vizualizare numită cu un prefix tbl care poate confunda unii dezvoltatori sau poate forța un alt strat, fie nivelul intermediar, fie aplicația să fie rescrisă pentru a face referire la noua mea structură sau nume de vizualizare. Aceasta neagă o mare parte din valoarea IMHO.

12
Shane Delmore

Tabele: plural

Mai mulți utilizatori sunt enumerați în tabelul utilizatorilor.

Modele: singular

Un utilizator singular poate fi selectat din tabelul utilizatorilor.

Controlere: plural

http://myapp.com/users ar enumera mai mulți utilizatori.

Oricum asta mă ocup de asta.

12
Andrew

Sistemul tables/views al serverului în sine (SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns etc.) sunt aproape întotdeauna plural. Bănuiesc că, din motive de consecvență, le-aș urma.

11
Michel

Alternative posibile:

  • Redenumirea tabelului SystemUser
  • Folosiți paranteze
  • Păstrați numele tabelului plural.

IMO folosind paranteze este tehnic cea mai sigură abordare, deși este un pic greoaie. IMO este 6 din una, jumătate de duzină din cealaltă, iar soluția ta se reduce pur și simplu la preferințele personale/echipei.

9
Dave Markle

Poate fi redundant, dar aș sugera să fii prudent. Nu neapărat că este un lucru rău să redenumiți tabelele, dar standardizarea este tocmai asta; un standard - această bază de date ar putea fi deja „standardizată”, oricât de prost :) - Aș sugera ca consistența să fie un obiectiv mai bun, având în vedere că această bază de date există deja și, probabil, constă din mai mult de doar 2 tabele.

Dacă nu puteți standardiza întreaga bază de date sau, cel puțin, intenționați să lucrați în acest scop, bănuiesc că numele tabelelor sunt doar vârful aisbergului și se concentrează asupra sarcinii la îndemână, rezistând durerii obiectelor slab numite, pot fi în interesul dvs. cel mai bun -

Coerența practică este uneori cel mai bun standard ... :)

my2cents ---

9
Borzio

Preluarea mea este în semantică, în funcție de modul în care vă definiți containerul. De exemplu, o „pungă cu mere” sau pur și simplu „mere” sau o „pungă Apple” sau „Apple”.

Exemplu: un tabel „colegiu” poate conține 0 sau mai multe colegii, un tabel de „colegii” poate conține 0 sau mai mulți colegi

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

Concluzia mea este că fie este bine, dar trebuie să definiți modul în care voi (sau persoanele care interacționează cu acesta) veți aborda atunci când vă referiți la tabele; "o tabelă x" sau o "masă de x"

9
jleviaguirre

Dacă ne uităm la tabelele de sistem MS SQL Server's, numele lor atribuite de Microsoft sunt în plural.

Tabelele de sistem ale lui Oracle sunt numite în singular. Deși câteva dintre ele sunt plural. Oracle recomandă plural pentru numele tabelelor definite de utilizator. Nu are sens că recomandă un lucru și urmează altul. Că arhitecții de la acești doi giganti software și-au numit tabelele folosind convenții diferite, nici nu are prea mult sens ... La urma urmei, care sunt acești tipi ... doctoranzi?

Îmi amintesc în academie, recomandarea a fost una singură.

De exemplu, când spunem:

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

poate b/c fiecare ID este selectat dintr-un anumit rând unic ...?

8
Richard

Am folosit întotdeauna singular doar pentru că asta am fost învățat. Cu toate acestea, în timp ce am creat recent o schemă recentă, pentru prima dată într-un timp îndelungat, am decis activ să mențin această convenție pur și simplu pentru că ... este mai scurtă. Adăugarea unui „s” la sfârșitul fiecărui nume de tabel mi se pare la fel de inutilă ca adăugarea „tbl_” în fața fiecăruia.

8
Just Some Guy

Cred că folosirea singularului este ceea ce am fost învățați la universitate. Dar, în același timp, puteți susțineți că, spre deosebire de programarea orientată pe obiect, un tabel nu este o instanță a înregistrărilor sale.

Cred că în acest moment sunt în favoarea singularului din cauza unor nereguli plural în engleză. În germană, este și mai rău din cauza formelor de plural consistente - uneori nu puteți spune dacă un Cuvânt este plural sau nu fără articolul specificat din fața sa (der/die/das). Și în limbile chineze, oricum nu există forme de plural.

8
helloworlder

Așa cum au menționat alții aici, convențiile ar trebui să fie un instrument pentru a adăuga ușurința de utilizare și lizibilitatea. Nu ca un cătuș sau un club pentru a tortura dezvoltatorii.

Acestea fiind spuse, preferința mea personală este să folosesc nume singulare atât pentru tabele cât și pentru coloane. Acest lucru provine probabil din fondul meu de programare. Numele claselor sunt în general singulare, cu excepția cazului în care sunt un fel de colecție. În mintea mea, păstrez sau citesc înregistrări individuale în tabelul respectiv, atât de singular are sens pentru mine.

Această practică îmi permite, de asemenea, să rezerv nume de tabel plural pentru cele care stochează relații între multe și multe dintre obiectele mele.

Încerc să evit cuvinte rezervate și în numele tabelelor și coloanelor. În cazul în cauză aici, are mai mult sens să contracarați convenția singulară pentru utilizatori pentru a evita necesitatea de a încapsula o tabelă care folosește cuvântul rezervat al utilizatorului.

Îmi place să folosesc prefixele într-o manieră limitată (tbl pentru nume de tabelă, sp_ pentru nume proc, etc), deși mulți cred că acest lucru adaugă dezordine. De asemenea, prefer numele CamelBack pentru subliniere, deoarece întotdeauna ajung să lovesc + + în loc de _ când tastează numele. Mulți alții nu sunt de acord.

Iată un alt link bun pentru denumirea orientărilor convenției: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/ =

Nu uitați că cel mai important factor al convenției dvs. este acela că are sens persoanelor care interacționează cu baza de date în cauză. Nu există „Un singur inel pentru a le regla pe toate” când vine vorba de denumirea convențiilor.

8
Chris

Întotdeauna am crezut că este o convenție mut. Folosesc nume de tabel plural.

(Cred că raționalul din spatele acestei politici este acela că ușurează generatoarele de cod ORM să producă clase de obiecte și colecții, deoarece este mai ușor să producă un nume plural dintr-un nume singular decât invers)

7
James Curran

Am folosit odată „Omul” pentru tabelul Utilizator - același număr scurt de caractere, niciun conflict cu cuvintele cheie, încă o referință la un om generic. Dacă nu m-ar fi preocupat de capetele umplute care ar putea vedea codul, aș fi păstrat-o așa.

7
Bruce Patin

Folosesc doar substantive pentru numele tabelelor care sunt ortografiate la fel, singular sau plural:

moose fish cerb avioane pantaloni scurți ochelari foarfece specii urmași

7
bobby

Orientările sunt într-adevăr acolo la fel. Nu este „pus în piatră”, de aceea aveți opțiunea de a le putea ignora.

Aș spune că este mai logic intuitiv să ai nume de tabel pluralizate. Un tabel este la urma urmei o colecție de entități. În afară de alte alternative menționate, văd în mod obișnuit prefixe pe numele tabelelor ...

  • tblUser
  • tblThis
  • tblThat
  • tblTheOther

Nu sugerez că acesta este calea de urmat, văd, de asemenea, spații utilizate un LOT în numele tabelelor pe care le abomin. Am întâlnit chiar nume de câmp cu personaje idioate ca? de parcă spunând că acest câmp răspunde la o întrebare.

5
BenAlabaster

Îmi voi da doar părerea de ce folosesc singular nume.

De exemplu, trebuie să obțin toate câmpurile de la un utilizator:

-- Select every fields from 'user' table
SELECT * FROM user

Am nevoie de numele utilizatorului care are 21 de ani:

-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'

Desigur, modalitatea plurală poate fi folosită prin aceleași mijloace, dar pentru a-mi citi creierul, cred cu adevărat că este calea cea bună.

5
nicruo

Definiția SQL a unui tabel este în realitate definiția unui rând potențial al tabelului, nu al colecției. Prin urmare, numele utilizat în această definiție trebuie să desemneze tipul rândului, nu numele colecției. Oamenii care preferă pluralul, deoarece citește bine în afirmațiile lor în limba engleză, trebuie să înceapă să gândească mai logic și să privească toate codurile logice și de programare care sunt implicate în utilizarea unui tabel. Există mai multe motive foarte bune menționate în aceste comentarii pentru a utiliza nume de tabel singulare. Acestea includ motive foarte bune pentru a NU folosi nume de tabel plural. „Citirea bine” nu ar trebui să fie deloc un motiv, mai ales că unii pot citi ideea altfel.

5
Bruce Patin

Dacă mergi, vei fi probleme, dar dacă rămâi, va fi dublu.

Mai degrabă aș merge împotriva unor presupuse convenții de denumire non-plural, decât să-mi numesc tabelul după ceva care ar putea fi un cuvânt rezervat.

4

Nu am văzut acest lucru clar în niciunul dintre răspunsurile anterioare. Mulți programatori nu au o definiție formală în minte atunci când lucrează cu tabele. Adesea comunicăm intuitiv în termeni de „înregistrări” sau „rânduri”. Cu toate acestea, cu unele excepții pentru relațiile denormalizate, tabelele sunt de obicei concepute astfel încât relația dintre atributele non-cheie și cheie să constituie o funcție teoretică setată.

O funcție poate fi definită ca un subset al unui produs încrucișat între două seturi, în care fiecare element al setului de taste apare cel mult o dată în mapare. Prin urmare, terminologia care rezultă din această perspectivă tinde să fie singulară. Se vede aceeași convenție singulară (sau cel puțin, non-plural) în alte teorii matematice și de calcul care implică funcții (algebră și lambda calcul, de exemplu).

4
jerseyboy

Folosesc întotdeauna nume de tabel singulare, dar, așa cum s-a spus deja, cel mai important este să fie consecvent și să folosesc aceeași formă pentru toate numele.

Ceea ce nu-mi place la numele tabelelor plural este că numele combinate pot deveni destul de ciudate. Dacă, de exemplu, aveți o tabelă numită Users și doriți să stocați proprietățile pentru utilizator, aceasta ar rezulta într-un tabel numit UsersProperties...

4
Vinz

Dacă utilizați anumite cadre precum Zend Framework (PHP), este înțelept să utilizați pluralul pentru clase de tabel și singular pentru clase de rând.

Așadar, spuneți că ați creat un obiect de tabel $ utilizatori = Utilizatori noi () și ați declarat clasa de rând drept Utilizator, veți putea apela și Utilizator nou ().

Acum, dacă folosești singular pentru numele tabelelor, ar trebui să faci ceva precum UserTable nou (), rândul fiind UserRow nou (). Acest lucru mi se pare mai stângaci decât să ai doar un obiect Utilizatori () pentru tabelă și Obiecte utilizator () pentru rânduri.

3
markus

Nu există nicio „convenție” care să necesite ca numele tabelelor să fie singulare.

De exemplu, am avut un tabel numit „REJECTS” pe un db utilizat de un proces de rating, care conține înregistrările respinse dintr-o execuție a programului și nu văd niciun motiv pentru a nu folosi pluralul pentru asta tabel (denumirea lui „REJECT” ar fi fost doar amuzant sau prea optimist).

Despre cealaltă problemă (ghilimele), aceasta depinde de dialectul SQL. Oracle nu necesită citate în jurul numelor de tabel.

3

Există diferite lucrări pe ambele site-uri, cred că trebuie doar să îți alegi partea. Personal prefer Plurar pentru denumirea tabelelor și, desigur, singular pentru denumirea în coloane.

Îmi place cum puteți citi acest lucru:

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

Într-adevăr, avem OOP și este excelent, dar majoritatea oamenilor folosesc baze de date relaționale, nu există baze de date obiect. Nu este necesară respectarea conceptelor OOP pentru bazele de date relaționale.

Un alt exemplu, aveți o echipă de masă, care păstrează TeamID, TeamColor, dar și PlayerID, și va avea același teamID și TeamColor pentru o anumită cantitate de PlayerID ...

Cărei echipă aparține jucătorul?

SELECT * FROM Teams WHERE PlayerID = X

Toți jucătorii de la echipa X?

SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

Toate aceste sunete bune pentru tine?

Oricum, aruncați o privire și asupra convențiilor de denumire folosite de W3Schools:

http://www.w3schools.com/sql/sql_join_inner.asp

2
hmartinezd

Un nume TABEL este UNUI definiția unei structuri de tabel. O denumire VEDERE sau ÎNCHIRIARE este O UNE definiție a unei vizualizări sau a interogării a (sau a multor) tabele. Un Tabel, Vizualizare sau ÎNCHIRIERE poate conține una dintre următoarele:

0 înregistrări 1 înregistrare Multe înregistrări.

De ce pe pământ ai vrea să pui un „s” la sfârșitul unui singur obiect de obiect? Ce doriți să semnificați, așezând această notă pe capătul unui nume de obiect?

Dacă doriți să diferențiați, atunci adăugați „_tbl”. O vedere este „_vew” (nu convenția stupidă „_v”).

Minim 3 caractere de sufixare - care oprește această discuție moartă.

Un tabel este un obiect DB - nu este diferit de oricare altul.

Salvarea a 3 caractere nu salvează nimic, cu excepția clarității semnificației.

Roșu ;-)

2
Red

În timp ce căutăm o bună legătură cu denumirea, apare următoarea confuzie, așa cum ar trebui să numesc:

1) acc. la ceea ce tabel reține de exemplu: Un tabel de utilizatori. Întotdeauna va fi plural. Deci, tilizatori

2) acc. la ceea ce un înregistrare deține de exemplu: o înregistrare în tabelele de utilizatori va face un singur utilizator. SO, tilizator.

Acum, problema pentru user_roles în principal. caz 1: acc. la prima convenție de denumire, users_roles Ce sugerează acest nume, utilizatorii și rolurile lor.

caz 2: acc. la a doua convenție de denumire, user_role Ce sugerează acest nume, utilizator și rolurile sale.

Convenția de numire bună este de a oferi o idee suplimentară a relațiilor Entitate , mai ales când sunt stocate mai multe relații.

Aici, în funcție de scenariu, ar trebui să ne identificăm ca seturi de informații.

În tabelul utilizatorilor, toate seturile formate sunt utilizator unic. În tabelul de roluri, toate seturile formate sunt roluri unice. În tabelul de relații între utilizatori și roluri, seturile de utilizatori pot fi formate cu roluri diferite, care oferă o idee despre 1-multe relații stocate.

I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles
2
Angelin Nadar

Am rezolvat aceeași problemă numind tabelul „Angajat” (de fapt „Angajați”). Încerc să stau cât mai departe de orice conflict cu cuvinte posibil rezervate. Chiar și „Utilizatorii” sunt inconfortabil apropiați pentru mine.

1
dkretz