2015-06-28 10:01 GMT+01:00 Simone Federici :
> ognuno ha le sue best practice, però alcune sono meglio delle altre.
>
E invece no. Il problema che io ho trovato e' proprio che ognuno ha le sue
best practice.
Disclaimer: io vengo dalla scuola in cui se uso un db relazionale, voglio
usare il model
> Il giorno 28/giu/2015, alle ore 11:01, Simone Federici
> ha scritto:
>
> DAC
https://it.wikipedia.org/wiki/DAC
https://en.wikipedia.org/wiki/DAC
Scusa l’ignoranza ma a quale DAC ti riferisci?
:D
G
___
Python mailing list
Python@lists.python.it
una chiave primaria composta da più colonne, è un DAC
è vero che "alcuni" db supportano where (tuonome, tuocognome) in (select
nome,cognome from anagrafica) ma mica è ANSI standard... e comunque le
performance di ricerca su indici compositi non è la stessa di un indice
numerico.
questo è il primo
> Il giorno 27/giu/2015, alle ore 18:17, Giovanni Porcari
> ha scritto:
>
>> Piu` che altro, mettere un id a tutti i costi non significa che il record da
>> esso identificato sia univoco. A tal proposito, Davide Bianchi scrisse un
>> articolo che esprime meglio il mio pensiero:
>> http://sof
2015-06-26 20:14 GMT+02:00 Gian Mario Tagliaretti :
> ma Genropy supporta le chiavi primarie multiple? Se non ricordo male
> solo SQL Alchemy le supporta, i modelli di Django solo la PK singola
> (sempre se ricordo bene)
>
Io di solito lascio a Django il compito di smazzarsi la PK con indice
nume
> Il giorno 27/giu/2015, alle ore 17:32, Enrico Bianchi
> ha scritto:
>
> On 06/27/2015 04:50 PM, Giovanni Porcari wrote:
>> Sono della fazione "ogni riga di tabella ha un identificativo univoco"
> Ma una chiave composita in cui tutti gli elementi assicurano l'univocita` del
> record e` un ide
On 06/27/2015 04:50 PM, Giovanni Porcari wrote:
Sono della fazione "ogni riga di tabella ha un identificativo univoco"
Ma una chiave composita in cui tutti gli elementi assicurano
l'univocita` del record e` un identificativo univoco ;)
Piu` che altro, mettere un id a tutti i costi non significa
> Il giorno 27/giu/2015, alle ore 15:48, Enrico Bianchi
> ha scritto:
>
> On 06/27/2015 02:27 PM, Gollum1 wrote:
>> Non ho capito
> E` male evitare una PK composita a favore di una PK generata, a meno che non
> ci sia un buon motivo per farlo (e.g. non c'e` univocita` dei record). Ma
> come d
Il 27 giugno 2015 15:48, Enrico Bianchi ha scritto:
> Ma come dice Riko, e` una guerra lunga e sanguinosa, con due fazioni convinte
> delle proprie posizioni... :)
Io sono della fazione per cui portarsi in giro una chiave fatta da N
colonne è meglio che comporne una nuova (duh) e portarsi in gir
On 06/27/2015 03:22 PM, Giovanni Porcari wrote:
Magari se dettagli un poco e argomenti si riesce meglio a comprendere
> ;)
Direi che gia` il dettaglio con cui ho risposto a Gollum e` esplicativo
del perche` dico che e` male per me :)
Enrico
___
Py
On 06/27/2015 02:27 PM, Gollum1 wrote:
Non ho capito
E` male evitare una PK composita a favore di una PK generata, a meno che
non ci sia un buon motivo per farlo (e.g. non c'e` univocita` dei
record). Ma come dice Riko, e` una guerra lunga e sanguinosa, con due
fazioni convinte delle proprie p
On 06/27/2015 02:25 PM, enrico franchi wrote:
E' una disputa lunghissima.
Piena di morti sul suo cammino, aggiungerei :)
Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
> Il giorno 27/giu/2015, alle ore 14:12, Enrico Bianchi
> ha scritto:
>
> On 06/26/2015 08:50 PM, Giovanni Porcari wrote:
>> Comunque, tranne in rarissimi casi preferiamo evitarle per facilità di
>> gestione.
> Il che e` male (anche come sono gestite, direi)
>
Risposta un tantinello scarna p
Il 27 giugno 2015 14:12:17 CEST, Enrico Bianchi ha
scritto:
>On 06/26/2015 08:50 PM, Giovanni Porcari wrote:
>> Comunque, tranne in rarissimi casi preferiamo evitarle per facilità
>di
>> gestione.
>Il che e` male (anche come sono gestite, direi)
>
>Enrico
>___
2015-06-27 13:12 GMT+01:00 Enrico Bianchi :
> Il che e` male (anche come sono gestite, direi)
>
E' una disputa lunghissima.
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
On 06/26/2015 08:50 PM, Giovanni Porcari wrote:
Comunque, tranne in rarissimi casi preferiamo evitarle per facilità di
gestione.
Il che e` male (anche come sono gestite, direi)
Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.
> Il giorno 26/giu/2015, alle ore 20:14, Gian Mario Tagliaretti
> ha scritto:
>
> Il 26 giugno 2015 18:15, Giovanni Porcari
> ha scritto:
>
> Giovanni,
>
>> In Genropy (come del resto in Django) per definire il model si scrive del
>> codice python.
>> Per progetti abbastanza grossi e con mo
Il 26 giugno 2015 18:15, Giovanni Porcari
ha scritto:
Giovanni,
> In Genropy (come del resto in Django) per definire il model si scrive del
> codice python.
> Per progetti abbastanza grossi e con moltissime tabelle e campi (oppure per
> piccoli progetti
> in mano a sviluppatori alle prime armi
18 matches
Mail list logo
