🚀 go-pugleaf

"Ulrik Buchholtz" <ulrikb@gmx.net> wrote in message
news:87zobekbrq.fsf@gmx.net...
>
> 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?

Relationer er logiske - det du definere er referential-integritet, at man s�
tit bruger de samme referencer i forbindelse med join's er en
"tilf�ldighed".

>
> 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
>
>
> 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?

Well, hvis jeg har forst�et hvad det er du vil s� ville

string_id, language_id, text

fungere ganske udem�rket, du laver s� bare et "compound" indeks p�
string_id, language_id. Du skal nok lige kigge p� om du skal indeksere med
string_id eller language_id f�rst - det vil afh�nge af hvordan du laver
udtr�kket. Et sprog af gangen og alle tekster s� start med language_id
ellers skal du nok bare bruge det med string_id f�rst.

Som sagt jeg er ikke helt sikker p� hvad det er du vil men hermed et skud i
t�gen......



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