<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"> Column |          Type          | Modifiers</div>
--------+---------------------<u></u>---+-----------<br>
 name   | character varying(100) | not null<br>
 author | character varying(100) | not null   <- nota: non ce l'ho </blockquote><div><br></div><div>fantastico immagino che posso dire di essere un emerito cretino :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

test=> insert into book values ('titolo', null);<br>
ERROR:  null value in column "author" violates not-null constraint</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sulla terra no. Postgres come vedi sopra forza le pkey a essere non null. Altri db forse non aggiungono questo vincolo, ma questo non vuol dire sia una cosa ragionevole da fare.<br></blockquote><div><br></div><div>base terra chiama => marte </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Una relazione generica io non nego sia utile: quello che sostengo è che i db relazionali sono fatti *apposta* per prendere vantaggio dalle relazioni specifiche. In un db crei il modello di un dominio. Se vuoi una relazione specifica, vuol dire che stai modellando l'oggetto di base, l'"oggetto", e non gli oggetti che fai. Come dire, traslato in mondo Python, che le classi sono oggetti di primo ordine. Se tu nel database modelli "la classe" e "l'istanza" allora puoi fare relazioni generiche: praticamente metterai tutti i tuoi oggetti in una sola tabella e anzichè dire "seleziona tutti i libri" dirai "seleziona tutti gli oggetti che sono di tipo libro".<br>

 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fa cagare vero? Certo che lo fa. Ma così fai le cose generiche in un db. Dire "generico" e poi avere gli oggetti in diverse tabelle, cioè fare oggetti specifici, sono due modelli diversi, e non puoi applicare al secondo le caratteristiche del primo.<br>


<br>
Insomma: secondo me stai over-generalizzando dove non puoi - stai provando a trattare tabelle specifiche come oggetti generici. Sopra questo stai over-over-generalizzando considerando pkey composte. Sopra questo stai over-over-over-generalizzando considerando valori non ragionevoli per le pkey. </blockquote>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
E dici a me di restare a terra?</blockquote><div><br></div><div>Non c'è che dire che ho preso na' toppa ponendomi un problema che non esiste.</div><div><br></div><div>Per le relazioni generiche invece dissento.</div>

<div>L'utilità della relazione è indiscutibile, e anche se non è in una forma che può essere definita "da manuale del vero DBA" è comunque uns tandard che stà diventando de facto, ho visto parecchi shema che stanno evelvendo con il concetto di content type.</div>

<div><br></div><div>E dai l'hai detto pure tu che il mono tabella fa cagare quindi perche sputare su una soluzione ibrida?</div><div>comunque il mio proposito è quello di dare una features in più a Django che adesso non ha, quindi non la posso dare dicendo: </div>

<div>"non usate le generic relation cretini :-)"</div><div><br></div><div><br></div><div>grazie della dritta, vuol dire che 1 stavo correndo a occhi bassi, 2 che la soluzione che ho postato nella prima mail è già la soluzione definitiva</div>

<div><br></div><div>ciao</div></div>