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
[email protected]
http://lists.python.
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
[email protected]
http://lists.python.it/mailman/listinfo/python
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
>___
> 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
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
[email protected]
http://lists.python.it/mailman/listinfo/python
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 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
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/25/2015 11:38 PM, Gabriele Battaglia wrote:
Io sono disponibilissimo e anzi, mi farebbe un piacere incredibile se qualcuno
che ci legge, volesse prepararmi un piccolo eseguibile scritto con questa
“roba”..:) Nominata da Germano.
Guarda, se non ho capito male il test del tizio che aveva p
> 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
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 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
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 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
14 matches
Mail list logo
