<div class="gmail_quote">2012/3/21 Daniele Varrazzo <span dir="ltr"><<a href="mailto:piro@develer.com">piro@develer.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Tue, 20 Mar 2012 22:12:45 +0100, Simone Federici wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dato queste coppie di chiavi<br>
<br>
keys = [<br>
    ("LDAP server", "Agent"),<br>
    ("-LDAP-server-", "_S-"),<br>
    ("Pippo'", "'pluto"),<br>
    ("Pippo", NULL)<br>
    ("Pippo", "")<br>
]<br>
</blockquote>
<br></div>
Se c'è un null, non è una chiave.<br></blockquote><div><br></div><div>eeee magari fosse cosi facile :-)</div><div><br></div><div>qui apriamo una enorme discussione filosofica su cui probabilmente la vediamo allo stesso modo. Però scendiamo sulla terra e vediamo cosa abbiamo:</div>

<div><br></div><div>CREATE TABLE "book" (</div><div><div>    "name" varchar(100) NOT NULL,</div><div>    "author" varchar(100),</div><div>    CONSTRAINT pk PRIMARY KEY ("author", "name")</div>

<div>)</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...] snippo: stavo dando risposte che a rileggerle sono troppo sarcastiche e poco utili: non ti faccio perdere tempo e non rischio incazzature che non desidero.</blockquote><div><br></div><div>ma no a me piace la vena sarcastica, sadica e tutta la trafila, vai pure sfogati :-)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
spiegazione lunga -> potete non leggerla e aiutarmi comunque a risolvere il<br>
problema :-)<br>
è per la risoluzione di un problema per le chiavi composte per django, in<br>
relazione alle sue generic relations, dove django va a scrivere la chiave<br>
(content_id), essendo una app che deve andare bene per tetti i modelli<br>
 (guarda ad esempio il log dell'admin), deve funzionare anche con i modelli<br>
che hanno una chiave composta, quindi cosa ci scrivo dentro il content_id,<br>
qualcosa che mi concateni le parti delle chiavi e che però sia calcolabile<br>
anche con SQL per inserirlo nelle join tra le tabelle.<br>
<a href="https://github.com/simone/django-compositekey" target="_blank">https://github.com/simone/<u></u>django-compositekey</a><br>
</blockquote>
<br></div>
Senza entrare nel merito di quello che provi a fare in sql che forse potrebbe essere fatto meglio in python, questo non aiuterebbe la reputazione che i database sono lenti a fare join. Passa a "generico" anziché "specifico" e tutto diventa magicamente 1000 volte più lento. Spero tu lo sappia e che ti basti quello che otterrai.<br>

</blockquote><div><br></div><div>Putroppo perfromance non è == a velocità e basta. Già la velocità è discutibile ma immagina una bella tabella di milioni di record, se per fare la query che ti serve prima devi fare un full table scan della tabella per prendere le chiavi e manipolare le chiavi comunque avresti un utilizzo della memoria non poco dispendioso che rischia di farti andare in out of memory. Basta pensare a 10 utenti che fanno la stessa operazione nellos tesso momento e hai un qualcosa che ti scoppia in mano. Bisogna lasciar fare le cose all'information expert di turno, lel qual caso per praticità è più facile farlo in python ma non è la scelta giusta IMHO :-)</div>

<div><br></div><div>Ad esempio ho scoperto che Mysql blocca la tabella dove deve scrivere quindi una update where pk in [subselect della stessa tabella] non si può fare, il che rende la mia implementazione inutile su mysql ma strautile in database un po' più seri.</div>

</div>