Discussione:
Consigli su nomenclatura tabelle e campi.
(troppo vecchio per rispondere)
Goldrake
2006-06-13 18:01:44 UTC
Permalink
Secondo la Vostra opinione, qual'e' il metodo migliore da utilizzare per
nominare le tabelle ed i campi pk e fk delle stesse ?

Se, per esempio, dovessimo creare un'anagrafica di modelli di automobili e
ogni modello avesse come proprietà la marca e la serie, io farei:

Tabella: MARCA
id (pk)
descrizione

Tabella: SERIE
id (pk)
descrizione

Tabella: MODELLI
id (pk)
idMarca (fk)
idSerie (fk)
descrizione

mettendo , ovviamente, in relazione le due fk (idMarca, idSerie) con le
relative pk delle tabelle Marca e Serie.

E' un buon metodo oppure è migliorabile ?

Grazie per i vostri consigli
Alessandro AKA Trinità
2006-06-13 18:59:02 UTC
Permalink
io per convenzione mia, la PK di una tabella la chiamo id_nometabella
Goldrake
2006-06-14 09:03:22 UTC
Permalink
Post by Alessandro AKA Trinità
io per convenzione mia, la PK di una tabella la chiamo id_nometabella
E la FK relativa alla PK , come la chiami ?

Ciao
Marcello
2006-06-14 09:41:44 UTC
Permalink
Post by Goldrake
Post by Alessandro AKA Trinità
io per convenzione mia, la PK di una tabella la chiamo id_nometabella
E la FK relativa alla PK , come la chiami ?
Ciao,

si tratta di scelte molto personali che variano secondo il proprio gusto
e il proprio concetto di leggibilità, personalmente per la PK
[surrogata] uso la dicitura ID_<Singolare> e per la tabella t_<Plurale>.
Il nome della PK lo ripeto identico nelle FK esterne, nell'esempio che
porti io scriverei [in pseudo-TSQL]:

Create table t_Marche(ID_Marca primary key,descrizione)
Create table t_Serie(ID_Serie primary key,descrizione)
Create table t_Modelli(ID_Modello primary key,ID_Marca,ID_Serie,Descrizione)

Facendo uso abbastanza massiccio di reflection la presenza di plurale e
singolare può permettere giochini interessanti sulla composizione
automatica di messaggistica.
Inoltre utilizzo rigorosamente il prefisso ID_ per le chiavi, anche
questo in un'ottica di reflection.
Ancora, consiglio un buon uso di lower e upper case. Considera la
tabella ipotetica "Ordini a fornitore". Un nome in lower case con
iniziali maiuscole permette a mio avviso una buona lettura e, anche qui,
reflection via separazione automatica delle maiuscole, quindi la tabella
potrebbe chiamarsi t_OrdiniAFornitore.
Una strategia di questo tipo permette tra l'altro di scrivere viste
compatte senza spazi e lasciare che sia il client a rianalizzare la
camptions. Supponimo per esempio di avere una vista del tipo:

create view v_Automobili
as
Select ID_Automobile, TipologiaAutoveicolo,
DecrizioneEstesa,NumeroMatricola, NumeroTarga
...

Un client "esperto" che intenda buttare i dati provenienti da questa
vista in un griglia potrebbe rinominare le colonne,eseguire la
separazione automatica delle maiuscole e l'analisi dei campi surrogati e
proporre una roba del tipo:

Caption: "Automobili" [lo recupera dal nome della vista stesso]
Colonne: ID_Automobile [Non lo viualizza poichè la caption contiene il
prefisso ID_ e quindi è un surrogato]
"Tipologia Autoveicolo"
"Descrizione Estesa"
"Numero Matricola"
"Numero Targa"

Un sistema esperto potrebbe, per esempio sul doppio click in griglia,
aprire una finestra di edit con caption "Modifica Automobile" [Il
singolare lo recupera dal nome dell'ID!] e volendo spingersi più in là,
il fatto che quel dato fosse editabile potrebbe essere recuperato
automaticamente dall'esistenza o meno di storeds con una corretta naming
convention [chessò, p_Automobili_Save].

Insomma tutto ciò per dire che tutto sommato qualunque naming convention
va bene, basta, a mio avviso, che :

- Non richieda troppa fatica [robe del tipo
t_<NomeCreatore>_<NomeSezione>_<NomeOggetto>_<Specifiche> non servono a
nessuno e sono sfiancanti]
- Abbia un'utilità [le naming convenctions fini a se stesse fanno solo
venire il nervoso a chi deve sottostarvi].

e che da una buona naming convenction i posso ricavare un sacco di belle
cose :-D
Post by Goldrake
Ciao
marc.
--
Marcello Poletti
Dingo&Epomops
http://www.epomops.it
http://blogs.dotnethell.it/epomops/
Goldrake
2006-06-19 07:59:52 UTC
Permalink
Grazie mille per le dritte.
Le ho trovate utilissime

A presto
Post by Goldrake
Post by Alessandro AKA Trinità
io per convenzione mia, la PK di una tabella la chiamo id_nometabella
E la FK relativa alla PK , come la chiami ?
Ciao,
si tratta di scelte molto personali che variano secondo il proprio gusto e
il proprio concetto di leggibilità, personalmente per la PK [surrogata]
uso la dicitura ID_<Singolare> e per la tabella t_<Plurale>. Il nome della
PK lo ripeto identico nelle FK esterne, nell'esempio che porti io
Create table t_Marche(ID_Marca primary key,descrizione)
Create table t_Serie(ID_Serie primary key,descrizione)
Create table t_Modelli(ID_Modello primary
key,ID_Marca,ID_Serie,Descrizione)
Facendo uso abbastanza massiccio di reflection la presenza di plurale e
singolare può permettere giochini interessanti sulla composizione
automatica di messaggistica.
Inoltre utilizzo rigorosamente il prefisso ID_ per le chiavi, anche questo
in un'ottica di reflection.
Ancora, consiglio un buon uso di lower e upper case. Considera la tabella
ipotetica "Ordini a fornitore". Un nome in lower case con iniziali
maiuscole permette a mio avviso una buona lettura e, anche qui, reflection
via separazione automatica delle maiuscole, quindi la tabella potrebbe
chiamarsi t_OrdiniAFornitore.
Una strategia di questo tipo permette tra l'altro di scrivere viste
compatte senza spazi e lasciare che sia il client a rianalizzare la
create view v_Automobili
as
Select ID_Automobile, TipologiaAutoveicolo,
DecrizioneEstesa,NumeroMatricola, NumeroTarga
...
Un client "esperto" che intenda buttare i dati provenienti da questa vista
in un griglia potrebbe rinominare le colonne,eseguire la separazione
automatica delle maiuscole e l'analisi dei campi surrogati e proporre una
Caption: "Automobili" [lo recupera dal nome della vista stesso]
Colonne: ID_Automobile [Non lo viualizza poichè la caption contiene il
prefisso ID_ e quindi è un surrogato]
"Tipologia Autoveicolo"
"Descrizione Estesa"
"Numero Matricola"
"Numero Targa"
Un sistema esperto potrebbe, per esempio sul doppio click in griglia,
aprire una finestra di edit con caption "Modifica Automobile" [Il
singolare lo recupera dal nome dell'ID!] e volendo spingersi più in là, il
fatto che quel dato fosse editabile potrebbe essere recuperato
automaticamente dall'esistenza o meno di storeds con una corretta naming
convention [chessò, p_Automobili_Save].
Insomma tutto ciò per dire che tutto sommato qualunque naming convention
- Non richieda troppa fatica [robe del tipo
t_<NomeCreatore>_<NomeSezione>_<NomeOggetto>_<Specifiche> non servono a
nessuno e sono sfiancanti]
- Abbia un'utilità [le naming convenctions fini a se stesse fanno solo
venire il nervoso a chi deve sottostarvi].
e che da una buona naming convenction i posso ricavare un sacco di belle
cose :-D
Post by Goldrake
Ciao
marc.
--
Marcello Poletti
Dingo&Epomops
http://www.epomops.it
http://blogs.dotnethell.it/epomops/
Continua a leggere su narkive:
Loading...