On Wed, 21 Mar 2012 14:30:08 +0100, Simone Federici wrote:
2012/3/21 Daniele Varrazzo <p...@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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Rispondere a