Re: 0.2.x DB

Am Montag, 13. September 2004 15:21 schrieben Sie:
> Hallo Thomas,
>
> es ist vermutlich besser wenn du auch immer auf die Liste postest. Ich
> denke die Diskussion sollte schon da geführt werden.
>
Ok, sorry, ich dachte, ich hätte es getan... Deshalb auch so wenig
Reaktionen ;)

> Thomas Mack wrote:
> > Ich bin gerade am Überlegen: was passiert z.B. mit einem See, der in
> > z.B. drei verschiedenen Ländern mit drei unterschiedlichen Sprachen
> > liegt? Und somit drei verschiedene "default_locale" haben könnte?
>
> Da ich selber nur an Städten interessiert bin, habe ich noch gar nicht
> daran gedacht, dass ihr sowas drin haben könntet.
> Der See läßt sich ja dann auch in keine strikte Hierarchie pressen, da
> er in 3 Ländern "enthalten" ist.
>
Kein Problem, weil wir problemlos drei Hierarchieen (und mehr) fuer
einen einzigen Ort definieren koennen.

> Der richtige Seename muß von der Anwendung im Sinne des Users
> rausgesucht werden. In der Sprache des Users oder in der Landesprache
> des Landes, das man gerade betrachtet.
>
> Mit Ozeanen/Meeren hat man das gleiche Problem.
> Der Atlantik z.B. hat sicher einen persischen Namen, obwohl der Iran
> nicht am Atlantik liegt. Aber man kann ja dann nicht einfach sagen wir
> nehmen französich als default, weil das am Atlantik liegt. Hier wird
> man in fast allen Fällen den Namen in der Sprache des Users abfragen.
> Wenn man aus Vereinfachunsgründen aber einen Default festlegen will,
> wäre ich immer für Englisch als Weltsprache. Das ist der einzig
> vernünftige Weg.
>
Ok fuer den Atlantik, aber Mailand - Milano - Milan: Default "Milan"? Das
geht wohl nicht an, oder?

Eigentlich geht es darum, dass man EINEN Namen fuer einen Ort bekommt.
Das funktioniert nicht mehr, wenn man mehrere "Defaultnamen" haben kann
wie beim See oben oder beim Atlantik oder beim Namen der Schweiz usw. usf..

Deshalb mein Vorschlag, mehrere Defaultnamen gleichzeitig zuzulassen,
was aber dem eigentlichen Sinn zuwiderläuft.

SELECT text_val
FROM geodb_textdata
WHERE loc_id=... AND text_type=NAME AND text_subtype=NATIVE

Das war mein Ansatz. Dann stellte sich heraus, dass da mehrere nicht-
unterscheidbare Namen bei herauskommen konnten. Schweiz / Suisse /
Svizzera als Beispiel.

Ok, packen wir noch eine Sprachoption hinzu und trennen wir uns
gleichzeitig vom "NATIVE" und machen ein Flag daraus (default_locale):

SELECT text_val
FROM geodb_textdata
WHERE loc_id=... AND 
      text_type=NAME AND
      locale like "de%" AND
      default_locale=true

Das Problem: man muss wissen, welche Defaultsprachen fuer diesen Ort
existieren.

So what? Was wollen wir erreichen? Es geht doch offensichtlich um
einen Ansatz, der EINEN eindeutigen Namen aus einem Namenspool
heraussucht. Und zwar auf der Ebene von SQL.

Wir koennten der Uebersicht halber mal eine eigene Relation mit
Defaultnamen erzeugen. Attribute: loc_id natuerlich, name und locale.
Jetzt packen wir dort hinein {..., Schweiz, de} {..., Suisse, fr}
{..., Svizzera, it}. Damit wir fuer einfache Anfragen EINEN
eindeutigen Wert bekommen, koennten wir einfach noch ein weiteres
Attribut dort mit hineintun:

loc_id
name
locale
is_default

und dann die Datensaetze ergaenzen: {..., Schweiz, de, true}
{..., Suisse, fr, false} {..., Svizzera, it, false}

DANN kann man Anfragen stellen nach dem Default vom Default, und
man erhält nur EINEN Datensatz

SELECT name
FROM geodb_default_names
WHERE loc_id=... AND 
      is_default=true

Alles andere was darüber hinausgeht, wie z.B. die Franzosen, die
sich wundern, warum sie "Schweiz" als Namen bekommen, und nicht
"Suisse" muessen etwas mehr Programmieraufwand betreiben.

Atlantik: fuer solche Orte waere es dann sinnvoll, alle Anrainersprachen
als default mit aufzunehmen und englisch als DEN Default zu bezeichnen.
Wobei der Atlantik schon ein Extremfall waere.

Und der See mit den drei Staaten? Hmmm, nehmen wir an, der Bodensee
wuerde in CH und A und D unterschiedlich heißen. Dann könnte man
hingehen, und behaupten, der Name in D waere DER Name: weil der
See flaechenmaessig den groeßten Anteil in D hat, wenn ich mich nicht
irre. Oder man sagt "Vorzugsweise wird der See so gesehen, dass er
in "..." liegt". Ein wenig Beliebigkeit: aber ich denke, wir koennten
es machen, einfach weil auch in der Annahme eine gewisse Beliebigkeit
liegt, dass es nur EINEN (richtigen) Namen gäbe: Wenn man es genauer
haben moechte, dann stehen die Mittel dazu bereit.

Oder sagen wir mal anders: ist es wirklich soooo wichtig, einen einzigen
Namen bekommen zu koennen?

...
Naja, ich koennte es mir schon vorstellen ;-)

Hmmm, mal schauen. Die Aufteilung in mehrere Relationen hat natuerlich
den Nachteil, dass man in der einen Relation sucht, aber der Datensatz
mal wieder ausschliesslich in der anderen Relation zu finden ist. Deshalb
waere die Aufnahme zusaetzlicher Attribute in geodb_textdata vielleicht
besser...

Tschüß,
Thomas