2012/3/21 Daniele Varrazzo <p...@develer.com>
> E, al di là delle prestazioni, il tuo problema è che vuoi offrire tutte le
> feature del db (più qualcuna che non esiste e ti sei inventato sul
> momento... ;) *e* relazioni generiche. Qui hai un problema diverso: con il
> db ci puoi fare tanto, i db relazionali consentono di creare strutture
> troppo generiche... per offrire relazioni generiche. Strano ma vero. E
> buona fortuna a combatterci contro questa natura.
io sono meno pessimista e visto che lo faccio nel tempo libero e la cosa mi
diverte, ancora meglio :-)
> Tra l'altro aggiungere una feature utile (pkey composte: hai tutto il mio
> appoggio) ma che finisce col non essere usabile con un'altra feature
> (generic relations: buone ma devi sapere quello che stai facendo) non
> sarebbe male comunque. Aggiungere una overgeneralizzazione che faccia
> andare django ancora più lento di quanto non sia... questo a me farebbe
> girare le scatole di più.
ma questo caso di cui parlo andrebbe a influenzare solo alcune query con le
relazioni generiche non tutto il resto del framework
cmq tornando al problema che è tuttaltro che risolto,
ci sono le FK che sono nullable :-)
quindi il problema mi si ripresenta da dietro l'angolo
CREATE TABLE sample_chapter
(
b_name character varying(100) NOT NULL,
b_author character varying(100),
num smallint NOT NULL,
title character varying(100) NOT NULL,
"text" character varying(100) NOT NULL,
CONSTRAINT sample_chapter_b_name_fkey FOREIGN KEY (b_name, b_author)
REFERENCES sample_book ("name", author) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT sample_chapter_b_author_b_name_num_key UNIQUE (b_author,
b_name, num),
CONSTRAINT sample_chapter_num_check CHECK (num >= 0)
)
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
