[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