🚀 go-pugleaf

Dette er nok et rimeligt hypotetisk (og rent teoretisk, for ikke at
sige langh�ret) sp�rgsm�l, men alligevel: hvordan konstrueres en
database, hvor et tilf�ldigt (alts� ikke et bestemt) felt kan have en
1-M relation med en tabel?

Normalt taler man om relationer tabeller imellem og felter imellem,
men ikke hvor felter i en tabel har en bestemt relation til en anden
tabel.

Problemet opst�r fx i den (hypotetiske?) situation, hvor alle
tekstfelter i en database skal v�re tilg�ngelige p� et vilk�rligt
antal sprog. Hvis det var to bestemte sprog kunne man have fx felt_en
og felt_da for hvert tekstfelt, men det g�r ikke, hvis der er mange
sprog, som man ikke kender p� designtidspunktet.

Jeg har forestillet mig noget a la f�lgende:

-- BEGIN SQL
CREATE TABLE string (
    string_id       INTEGER      NOT NULL PRIMARY KEY
);

CREATE TABLE language (
    language_id     INTEGER      NOT NULL PRIMARY KEY,
    code            CHAR(2)      NOT NULL CHECK (lower(code) = code),
    region          CHAR(2)      CHECK (lower(region) = region),
    name            INTEGER      NOT NULL REFERENCES string,
    UNIQUE(language_id, region)
);

CREATE TABLE string_language (
    string_id       INTEGER      NOT NULL REFERENCES string
                                 ON DELETE CASCADE,
    language_id     INTEGER      NOT NULL REFERENCES language
                                 ON DELETE CASCADE,
    string          TEXT         NOT NULL,
    PRIMARY KEY(string_id, language_id)
);

CREATE TABEL tabel (
    ...
    textfield       INTEGER      NOT NULL REFERENCES string,
    ...
);
-- END SQL

NB. Jeg ved godt, at 'TEXT'-typen ikke er defineret i SQL-92, men i
eksemplet ville en DBMS der havde den (eller lignende) nok v�re at
foretr�kke.

Problemet med ovenst�ende er (hvad jeg kan se):
  1. Det er grimt (IMHO). Hvorfor have en tabel med kun et felt.
  2. Forholdvist sv�rt at vedligeholde (vil jeg tro).
  3. D�rlig integritets-kontrol. Der er ingen kontrol med, at alle
     string-r�kker bliver refereret til af b�de en string_language og
     tabel.name.
  4. Det er enormt sv�rt at tr�kke data ud.

Kan nogen af jer komme p� et bedre bud p� en l�sning? Den skal v�re
liges� fleksibel p� den m�de at forst�, at alle tekstfelter skal
kunne forefindes p� et vilk�rligt antal sprog.

Der sp�rges ikke til hensyntagen til hastighed i f�rste omgang ;-)
En anden gang kan vi tage fuldtekst-s�gning i et vilk�rligt sprog i en
database a la denne p� 1TB!

-- 
Ulrik Buchholtz