[Python] Concatenazione lato DB => Rebus

Daniele Varrazzo piro a develer.com
Mer 21 Mar 2012 14:54:51 CET


On Wed, 21 Mar 2012 14:30:08 +0100, Simone Federici wrote:
> 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")
> )

Sulla terra, dove vivo io, abbiamo questo.

test=> CREATE TABLE "book" (
test(>     "name" varchar(100) NOT NULL,
test(>     "author" varchar(100),
test(>     CONSTRAINT pk PRIMARY KEY ("author", "name")
test(> );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "pk" for 
table "book"
CREATE TABLE
test=> \d book
              Table "public.book"
  Column |          Type          | Modifiers
--------+------------------------+-----------
  name   | character varying(100) | not null
  author | character varying(100) | not null   <- nota: non ce l'ho 
messo io
Indexes:
     "pk" PRIMARY KEY, btree (author, name)

test=> insert into book values ('titolo', null);
ERROR:  null value in column "author" violates not-null constraint
test=>

Forse sulla luna ci sono libri senza autore che hanno l'autore nella 
chiave primaria. Sulla luna sanno come risolvere il problema se due 
autori sconosciuti scrivono un libro con lo stesso nome, quello è lo 
stesso libro?

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.

----

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".

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.

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.

E dici a me di restare a terra?


-- 
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com


Maggiori informazioni sulla lista Python