"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