Nomenclatura tabelle e campi

[deleted_29]

Originariamente inviato da optime
io credo che Valeria si riferisse solo alla modalità di scrittura (RagioneSociale) per aumentare la leggibilità, e non intendesse usare il CamelCase per differenziare le colonne (es. RagioneSociale <> raGionesoCiale)

ma in cosa aumenta la leggibilità?

[optime]

Originariamente inviato da franzauker
ma in cosa aumenta la leggibilità?

vuoi farmi credere che per te AnagraficaFornitoriGruppiEsteriComunitari NON è più leggibile di ANAGRAFICAFORNITORIGRUPPIESTERICOMUNITARI

[deleted_29]

Originariamente inviato da optime
vuoi farmi credere che per te AnagraficaFornitoriGruppiEsteriComunitari NON è più leggibile di ANAGRAFICAFORNITORIGRUPPIESTERICOMUNITARI

no, perchè alla fine il campo va indicato sempre bene
... e non è insolito avere campi DC034, DC035, XB03

[optime]

quindi per te la "leggibilità" (non la correttezza) è la stessa. beh, sei un fenomeno, davvero

[alpynet]

Originariamente inviato da franzauker
no, perchè alla fine il campo va indicato sempre bene
... e non è insolito avere campi DC034, DC035, XB03

Ciao, è vero che spesso si trovano campi con nomi "anonimi", ed a livello "pratico" non cambia niente, ma personalmente la penso come optime. Avere un campo con un nome autodescrittivo, senza avere il tracciato sotto mano, aiuta molto a capire cosa contiene quel campo, e soprattutto aiuta molto anche a leggere le query e la manipolazione dei dati a livello di programmazione. Il CamelCase lo uso sempre nelle dichiarazioni di variabili a livello di programmazione, ma a livello database/tabelle/campi scrivo tutto in minuscolo e separo le parole con l'andescore: ragione_sociale, questo per il semplice motivo che ci sono rdbms che hanno problemi con il CamelCase: RagioneSociale (ad esempio con PostgreSql se il nome del campo è camelcase, per non avere problemi con le query, il nome del campo va messo tra apici).
Detto questo, mi sento di condividere a pieno la metodologia usata da Valeria75_bis.

[optime]

Originariamente inviato da franzauker
2) _? non servono a nulla, caratteri sprecati

mi piacerebbe avere dei chiarimenti su questa affermazione

[deleted_29]

Originariamente inviato da optime
mi piacerebbe avere dei chiarimenti su questa affermazione

sono caratteri come gli altri, personalmente non ho mai avuto particolari problemi con gli identificatori, nè lunghi nè corti, nè con _ nè senza.

perchè se non sai quale sia la "semantica" associata a codiceraccoglitore, conoscere la "sintassi" CoDiCe_RaCcOgLiToRe_Elenco_Depositi non ti aiuterà per nulla.


a mio modestissimo parere meno son complicati gli identificatori, meglio è.
meno regole "strane" (maiuscoleMinuscole) si hanno, meglio è.

una variazione della regola KISS: se è semplice, FORSE funziona

Tutto qui, niente di trascendentale o di particolare rilevanza

[optime]

Originariamente inviato da franzauker
sono caratteri come gli altri, personalmente non ho mai avuto particolari problemi con gli identificatori, nè lunghi nè corti, nè con _ nè senza.

una cosa è dire "non ho avuto problemi" una cosa è dire "non usarli"

[deleted_29]

Originariamente inviato da optime
una cosa è dire "non ho avuto problemi" una cosa è dire "non usarli"

OK, riformulo con "sconsiglio di usarli"

[optime]

Originariamente inviato da franzauker
OK, riformulo con "sconsiglio di usarli"

ok, rifaccio la domanda: di solito si sconsiglia l'uso di qualcosa perché potenzialmente può far male; in che modo l'uso di "_" nel nome dei campi o delle tabelle può far male? Non te lo domando tanto per fare polemica, ma per capire se effettivamente un domani posso andare incontro a problemi.