[Python] Concatenazione lato DB => Rebus

[Simone Federici]

2012/3/21 Daniele Varrazzo <piro a develer.com>

> On Tue, 20 Mar 2012 22:12:45 +0100, Simone Federici wrote:
>
>> Dato queste coppie di chiavi
>>
>> keys = [
>>    ("LDAP server", "Agent"),
>>    ("-LDAP-server-", "_S-"),
>>    ("Pippo'", "'pluto"),
>>    ("Pippo", NULL)
>>    ("Pippo", "")
>> ]
>>
>
> Se c'è un null, non è una chiave.
>

eeee magari fosse cosi facile :-)

qui apriamo una enorme discussione filosofica su cui probabilmente la
vediamo allo stesso modo. Però scendiamo sulla terra e vediamo cosa abbiamo:

CREATE TABLE "book" (
    "name" varchar(100) NOT NULL,
    "author" varchar(100),
    CONSTRAINT pk PRIMARY KEY ("author", "name")
)

[...] 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.


ma no a me piace la vena sarcastica, sadica e tutta la trafila, vai pure
sfogati :-)


>  spiegazione lunga -> potete non leggerla e aiutarmi comunque a risolvere
>> il
>> problema :-)
>> è per la risoluzione di un problema per le chiavi composte per django, in
>> relazione alle sue generic relations, dove django va a scrivere la chiave
>> (content_id), essendo una app che deve andare bene per tetti i modelli
>>  (guarda ad esempio il log dell'admin), deve funzionare anche con i
>> modelli
>> che hanno una chiave composta, quindi cosa ci scrivo dentro il content_id,
>> qualcosa che mi concateni le parti delle chiavi e che però sia calcolabile
>> anche con SQL per inserirlo nelle join tra le tabelle.
>> https://github.com/simone/**django-compositekey<https://github.com/simone/django-compositekey>
>>
>
> 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.
>

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 :-)

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.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20120321/7d126794/attachment.html>