Hallo Boris,
das sind genau die Punkte, die mir auch nie richtig gefallen haben.
Immerhin machst Du ein paar Lösungsvorschläge, ...
>ich bin gerade dabei noch weiter in die Strukturen der 0.2.x Version
>einzusteigen. Insgesamt ist das ganze doch deutlicher komplizierter als die
>0.1.x Versionen. Um umfangreiche Resultate zu bekommen sind einige Joins
>nötig. Mit Views läßt sich das vereinfachen, z.B.:
>
>CREATE VIEW geodb_typed_locations AS
>SELECT loc_id,name_id,language,name FROM geodb_locations AS a
>LEFT JOIN geodb_type_names AS b ON a.loc_type=b.type_id;
>
>Wenn man sich die Ausgaben dieses Views genauer anschaut, z.B.
>
>opengeodb2=# select * from geodb_typed_locations where loc_id=105;
> loc_id | name_id | language | name
>--------+---------+----------+-------
> 105 | 1 | de | Staat
> 105 | 2 | de | Land
>(2 Zeilen)
>
>fällt mir auf, dass in geodb_type_names, teilweise zwei Namensvarianten
>auftauchen. Die name_id ist scheinbar dafür gedacht, das zu unterscheiden.
>"Staat" und "Land" meinen das gleiche, nämlich type_id=100200000.
>
Das ist ein (der?) Grund, weshalb ich die Anfragen in der angepassten
opengeodb.php / GeoClass als EInzelanfragen implementiert hatte.
>Also ich finde das eher hinderlich und kompliziert. Man bekommt so immer
>zwei Ergebniszeilen und es ist nicht klar, welche zu verwenden ist.
Ich kenne das Problem.
>Joined man noch die eigentlichen Orstnamen dazu, wird es entsprechend noch
>unübersichtlicher. Ich denke man sollte sich hier für "Staat" oder "Land"
>entscheiden oder auch "Staat/Land". Das gleiche gilt für Kontinent und
>Erdteil. Es macht doch keinen Sinn hier alle Synonyme aufzuzählen. Im
>Zweifelsfall kann ja jede Anwendung, die die geodb verwendet, sowieso eine
>eigene Bezeichnung verwenden, das es ja intern eh einheitlich um die
>type_id 100200000 geht. Wenn man z.B. eine mehrsprache Anwendung macht,
>müßte man z.B. "Land" sowieso noch übersetzt anbieten usw.
>
Es ist mir eh nicht ganz klar, was der Sinn der geodb_type_names Relation
sein soll (auch wenn sie von mir stammt). Im Prinzip könnte man ganz
darauf verzichten. Und wenn man nicht darauf verzichtet? Wozu soll sie
gut sein? Was soll ihr Sinn sein? Dass jemand in einer Anwendung diese
Namen benutzt? Das wird eher nicht geschehen, denke ich mir.
Es ist höchstens dann von Bedeutung, wenn jemand direkt auf der DB arbeitet.
>Läßt man also die name_id gleich weg und bietet nur eine Variante an, kann
>man die type_id zum PRIMARY KEY machen und in den anderen Tabelle wo sie
>ausgiebig referenziert wird dann auch noch über REFERENCES ref. Integrität
>sicherstellen (1:n).
>
Ja...
>Weiterhin frage ich mich, wofür loc_subtype gedacht ist. Bisher ist es ja
>immer NULL.
>
Ja, das würde ich noch drinlassen, selbst wenn es z.Zt. wenig Sinn zu
machen scheint. Es gibt jede Menge von möglichen "locations", dass ich
mich nicht einschränken wollte. Andererseits: wenn das Problem auftritt,
dass man tatsächlich einen subtype benötigt, kann man ihn immer noch
ohen große Probleme hinzufügen, denke ich.
>Und welche genaue Bedeutung hat language? Was soll native_ aussagen? Könnte
>man nicht überall die ISO-Notaion mit sprache oder sprache_LAND verwenden?
Das war ein Gedanke. "NATIVE" heißt einfach, dass es die Bezeichnung ist,
die an genau diesem Ort üblich ist. Und damit kamen dann die ganzen Probleme
auf, weil z.B. Schweiz "native" Schweiz oder Suisse oder Svizzera heißen
kann. Oder Bozen auch Bolzano oder umgekehrt: Es gibt nicht nur EIN "Native",
sondern viele. Das wurde mir erst später bewußt. Und dann habe ich versuchsweise
daran herum gebastelt.
Nicht, daß es mir gefallen hätte...
Der Vorteil von "native" ist einfach, dass man unabhängig von einer
Spracheinstellung immer die ortsübliche Bezeichnung bekommt. Stellt
man auf "de", heißt Lisboa plötzlich Lissabon, stellt man auf
portugiesisch, heißen Orte in D vielleicht anders.
Und vor allem gibt es viele Orte, die eine deutsche Bezeichnung haben,
die aber heutzutage kaum noch üblich ist, wie z.B. Kronstadt in Rumänien,
das mittlerweile auch in D gemeinhin als Brasov bezeichnet wird.
Ok, man muss halt für jedes Land auf die Landessprache umschalten: das
dürfte kein sooo großes Problem sein. Aber "Native" wäre halt auch ganz
hübsch gewesen...
Übrigens: wie heißt die Schweiz in de_CH??? Svizzera z.B.? Oder anders?
Und Bautzen in de_DE? Budysin z.B.?
Aber wenn ich mich recht erinnere, kann man diese ISO Bezeichnungen um
Varianten erweitern. Es bleibt das Problem, dass man mehrere Bezeichnungen
für einen Ort bekommen kann. de_CH@de, de_CH@fr, de_CH@it? Aber kein
de oder de_CH mehr?
>Also de bei Kanton, statt native_CH? Dann ist genau definiert um welche
>Locale es sich handelt. Theoretisch könnten hier dann auch diverse
>Übersetzungen verzeichnet werden, z.B. "en" und "Canton".
>
Ja, so war das angedacht.
>Dummerweise ist die type_id dann aber auch wieder nicht eindeutig, d.h. die
>oben vorgeschlagene Strategie zur Verankerung der ref. Integrität ist nicht
>möglich. Aus Erfahrung mit datenbank-basierten mehrsprachigen Anwendungen
Naja, immerhin könnte man die type_id mit der language verknüpfen.
>würde ich auch immer dazu tendieren in der Datebank nur eine
>Standard-Sprache zu verwenden und die Übersetzung mindestens eine Ebene
>weiter oben in der Datenbank-Anwendung, am besten in der finalen
>Präsentationsschicht, zu machen. Bei Java geht das z.B. perfekt mit
>Resource-Bundles die auch genau dafür gedacht sind. Es könnte ja Teil des
>OpenGeoDB-Projektes sein, solche Dateien auch zu entwickeln und anzubieten,
>dafür müssen sie nicht in der Datenbank integriert sein. Das nutzen in
>anderen Sprachen wie z.B. PHP sollte kein Problem sein.
>
Das wäre vielleicht eine gute Lösung.
>Wie man es auch löst, grundsätzlich halte ich das Gleichsetzen von
>"Bundesland" und "Kanton" (beides type_id=100300000) auch nicht für 100%
>richtig, da es sich durchaus um unterschiedliche Sachen und nicht nur
>Übersetzungen (de_DE und de_CH) handelt.
>
Hmmm, naja, es gibt diese NUTS Hierarchieen, und eigentlich geht es nur
darum. NUTS I, NUTS II, NUTS III: in verschiedenen Ländern heißen diese
Verwaltungsebenen halt unterschiedlich.
Grüße,
Thomas
|
