Newsgroup: it.comp.software.database
Titolo: Naming conventions

Ciao a tutti,
qualcuno ha qualche link su come seguire degli standard di denominazione
per i database?
Es:
Tabella CLIENTI e CLIENTE
Campo IDClienti o IDCliente
La FK eventuale come dovrebbe essere chiamata?
Insomma delle regole generiche, non da seguire come bibbia, ma delle quali
tenere conto.
Esiste qualcosa? Magari per microsoft direttamente?

 denominazione per i database?
Qualche piccolezza sul vecchio thread gemello:
http://groups.google.it/group/it.comp.software.database/browse_thread/thread/9ccd078781044097/
In seguito avevo fatto qualche ricerca, ma non ho trovato niente di
convincente. Se trovi posta grazie ciao

 convincente. Se trovi posta grazie ciao
Grazie, leggo subito.
E' che seguendo un webcast ho sentito una frase del genere:
"chiamamo la tabella xxxxx secondo le nuove conventions di microsoft".
Quindi ero maggiormente curioso.


Sostanzialmente dice di chiamare le tabelle al singolare, cosa che
ovviamente io non ho.
Io ho ARTICOLI, CLIENTI ecc. non ARTICOLO, CLIENTE...
Siccome mi trovo a dover progettare nuove tabelle per un applicativo,
volevo prendere una regola.
Inoltre i nomi dei campi
<Tabella>_campo
Ma questa mi pare un po' troppo prolissa, tanto nomi duplicati gli ho gi�,
inutile integrarli ora :)

 inutile integrarli ora :)
e come ti trovi?
e' una domanda serissima :o)
ciao
Rob

 e' una domanda serissima :o)
Era un DB semi costruito in quel modo.
Di solito nelle query scrivo sempre gli alias, per cui non ho problemi
pratici.

 inutile integrarli ora :)
O mamma... prolissa e' dir poco! Non mi piace per niente. E' anche
peggio
della notazione ungherese! Io uso quella convenzione solo per i nomi
duplicati: SELECT tab1.codice as TAB1_CODICE, tab2.codice as
TAB2_codice, ...
ciao
Giacomo

salve Andrea,

leggo Davidson in  
http://www.apress.com/book/view/1590595297
:
pag 68 , "best practices":
- enitity names: There are 2 ways to you can go with these, plural or 
singular. I feel that names should be singular (meaning the name of the 
table describes a single instance, or row, of the entity, much like an OO 
object name describes the instance of an object, not a group of them), but 
many other highly regarded data architects and authors feel that the table 
name refers to the set of rows and should be plural. Wichever way you decide 
to go, it's most important that you are consistent. Anyone reading your 
model shouldn't have to guess why some entity names are plural and others 
aren't.
- attribute names: It's generally not necessary to repeat the entity name in 
the attribute name, except for primary key. The entity name is implied by 
the attribute inclusion in the entity. The chosen attribute name should 
reflect precisely what is contained in the attribute and how it relates to 
the entity. And as with entities, no abbreviations are to be used in  the 
logical naming of attributes; every word should be spelled out in its 
entirety. If any abbreviation is to be used, due to some naming standard 
currently in place, for example, then a method should be put into place to 
make sure the abbreviation is used consistently, as discussed earlier in 
this chapter.
prosegue poi con le relazioni, domini ed altri database objects..
diversamente, Celko (
http://www.celko.com/books.htm
) dedica un intero 
capitolo all'argomento in SQL Programming Style ed e' difficilmente 
riassumibile per la "vastita'" dell'informazione.. ovviamente il nostro basa 
molte argomentazioni sugli standard ANSI/ISO,  dei quali si puo' avere 
parzialmente visione in 
http://pueblo.lbl.gov/~olken/X3L8/drafts/draft.docs.html
personalmente non ho solitamente necessita' di porting come piu' e piu' 
volte ripetuto e formalizzato da Celko e apprezzo molto la forma mentale di 
Davidson.. al di la' di cio', il libro di Celko e' sicuramente un'ottima 
lettura, grande spunto di stile e fonte di riflessione..
personalmente i nomi delle tabelle li uso al plurale perche', come gia' da 
altri riportato, mi esprimono il concetto di "insieme" e non di singola 
istanza o riga.. diversamente da Davidson anche per le colonne in chiave 
(primaria o meno) non prefisso l'attributo con il nome dell'entita' 
stessa... per le relazioni mi piace indicare l'origine della stessa nei 
termini "is a" ovvero "has a/many" utilizzando "$" come separatore quindi
ALTER TABLE Employees
    ADD CONSTRAINT [fk_Employee$is$Person] (Id)
        FOREIGN KEY
        REFERENCES Persons (Id)
e similarmente nomino le procedure con poco pragmatismo quale
CREATE PROCEDURE usp_Persons$GetPersonById (
    @Id int
    )
AS BEGIN...
(ovviamente non ho assolutamente bisogno di ricordartelo che' sei da anni 
sul campo) e' tendenzialmente fondamentale di essere consistenti :)
saluti
-- 
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz
DbaMgr2k ver 0.21.1 - DbaMgr ver 0.65.1 and further SQL Tools
http://www.hotelsole.com
 - 
http://www.hotelsolericcione.de
--------- remove DMO to reply 

 sul campo) e' tendenzialmente fondamentale di essere consistenti :)
Difficile farlo quando "parti male" con una base di cui non sei
responsabile :)
E quando la teoria non hai tempo di applicarla, e alla fine la dimentichi
:)

Visto che sono stati menzionati entrambi gli autori dei libri,
sara` interessante notare come gli stessi sono intervenuti sul tema
"Why plural table names?"
http://groups.google.it/group/microsoft.public.sqlserver.programming/browse_thread/thread/8fe314876b29abb5/a471154744d10198?hl=it

 istanza o riga..
Niente su queste tabelle non riesco a dare nomi decenti e seguire una
linea.
Tabelle:
Tecnico (inteso come persona)
TecnicoSquadra (un insieme che raggruppa pi� tecnici)
TecnicoTipo (es. elettricista, falegname)
Avevo provato con i plurali "soliti" ma mi veniva
Tecnici
TecniciSquadra (o TecniciSquadre o TecnicoSquadre?)
TecniciTipo (o TecniciTipi o TecnicoTipi?)
Insomma con i singolari vien meglio.
E mettere la nomenclatura della prima parte di tabella uguale a quella da
cui son consumati � corretto o no?
tecnicoSQUADRA, tecnicoTIPO
Per assonanza si dice prima TipoTecnico e SquadraTecnico, ma nell'altro
modo le tabelle sono tutte allineate, e si capisce subito la dipendenza
dell'una.
Il problema � se si ha un ulteriore livello, esempio per assurda
TecnicoSquadraQualifica, che diventa improponibile.
E soprattutto se tale tabella dovesse essere usata da altre tabelle nuove
in futuro.

 TecnicoSquadraQualifica, che diventa improponibile.
si. ma se scegli una naming convention, devi seguirla.
e' ovvio che situazioni complesse/scomode ne troverai
sempre...
ultima cosa, io ho fatto delle piccole ricerche informandomi
su quale tipo di naming utilizzano alcuni famosi software opensource
puoi provare anche tu...
ciao
Rob

 puoi provare anche tu...
Realmente pensavo ci fosse qualcosa di pi� definito, invece alla fine posso
adottare lo standard che ho usato sempre, che non mi pare molto diverso da
alcuni altri.
Nomi tabelle plurali, il campo id riporta il nome della tabella, gli altri
campi non necessariamente.
Ora volevo risparmiare un po' di campi autoincrement, ma da qualche parte
mi fa comodo che ci siano, anche perch� sto per affrontare una situazione
in cui ci sono 5/6 tabelle ognuna � un Detail dell'altra, quindi con chiavi
composte, si arriverebbe alla fine ad avere per l'ultima tabella 8/9 campi
per comporre la chiave, decisamente scomodo.