[MontelLUG] A proposito di SQL e database - domanda inerente al corso di SQLite

[Davide Posillipo]

Ciao Marco,

grazie mille, sinceramente, della tua fantastica risposta; mi hai chiarito
diversi punti importanti.
Nel mio caso i valori dovrebbero essere in teoria praticamente "eterni" in
quanto non è prevista una successiva interazione da parte di utenti per
modificare il db. Accedo direttamente con SQL.

L'idea di usare un costraint unique mi intriga e ammetto che non ci avevo
pensato, però mi porta ad un'altra difficoltà tecnica dovuta al tipo di
implementazione della base di dati che sto progettando.
In pratica verrà popolata tramite un programma Java che con JDBC leggerà un
flusso indefinito di file XML dallo schema costante e scriverà sul db i
dati estratti.
Il punto è che sto scrivendo anche il programma e almeno così su due piedi
mi sembra più facile definire una chiave primaria formata da campi già
esistenti che crearne una di tipo integer che poi il programma deve
aggiornare e verificare in automatico (non sono espertissimo di Java).

Però l'idea mi sembra eccellente e ne farò sicuramente uso in futuro, anche
perché al momento tratto con db che non superano i dieci milioni di record.

Grazie ancora di cuore della risposta e degli spunti da esperto :)


Il giorno 25 settembre 2014 16:57, Marco De Paoli <depaolim a gmail.com> ha
scritto:

> ciao Davide,
>
> Il 25 settembre 2014 16:26, Davide Posillipo <dav.posillipo a gmail.com>
> ha scritto:
> > Buongiorno a tutti,
> >
> > sto cercando di realizzare una base di dati relazionale a partire da un
> > modello ER che ho man mano ridotto eliminando entità e relazioni che mi
> > sembravano ridondanti.
> >
> > Ora che sto traducendo il tutto in termini di relazioni (tabelle), mi
> sono
> > accorto che una di queste relazioni ha come chiave primaria una chiave
> > composta da quattro attributi.
> >
> > La mia domanda è: avere relazioni con chiavi primarie composte da diversi
> > attributi potenzialmente può portare a situazioni problematiche? Qual è,
> se
> > esiste, un compromesso accettabile tra numero di relazioni e non
> ridondanza
> > delle informazioni (senza ricorrere alle forme normali)?
>
> in linea di massima ti direi che dipende da un sacco di cose
> il tipo di questi campi? i valori, una volta caricati, sono veramente
> scolpiti nella roccia oppure potrebbero cambiare? come accedi alla
> base dati? direttamente in SQL oppure usi un ORM? l'ORM ha dei limiti?
> (es. vuole solo chiavi singole? ce ne sono ce ne sono...)
>
> io per esempio tendo a definire una singola chiave primaria id di tipo
> integer e ottenere in questo modo criteri di join e foreign key puliti
> puliti
>
> ovvio che poi se voglio un vincolo di unicità su una tupla composta da
> più campi mettero un constraint unique sulla combinazione dei campi
>
> (a quel punto ti creerà anche un indice unique che quindi ti velocizza
> le ricerche con quel criterio)
>
> certo ti ritroverai con due indici (la chiave primaria più lo unique)
> quando potresti averne uno solo...
>
> ok, ma con il costo moderno degli storage non è un grosso problema
>
> mi potresti obiettare che due indici significa anche doppio
> aggiornamento in caso di insert/update. Ok, ma anche le i cicli di
> clock delle CPU non costano poi così tanto ;-)
>
> perchè soprattutto, se effettivamente i valori dei campi in chiave
> possono modificarsi nella "storia" del record
> tanto più se sono più di uno
>
> Beh, il fatto di tenere consistenti le foreign key sarà una cosa che
> ti devi smazzare tu da logica applicativa, mentre invece se sono
> collegati per id sono legati per sempre e non ci pensi più
>
> insomma torniamo alla mia osservazione iniziale: dipende
> certo, se stiamo parlando di centiania di milioni di record magari la
> cosa ha il suo impatto... parliamone
>
> just my 2 c
>
> >
> > Grazie per l'attenzione,
>
> de nada,
> a proposito, non credo di aver ancora mai partecipato attivamente alla
> lista
> per cui ... ciao a tutti!
>
> Marco
> _______________________________________________
> montellug mailing list
> montellug a montellug.it
> http://mail.montellug.it/mailman/listinfo/montellug
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://mail.montellug.it/pipermail/montellug/attachments/20140925/4e2847ba/attachment-0001.html>