0.2.x DB

Hallo,

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.

Also ich finde das eher hinderlich und kompliziert. Man bekommt so immer
zwei Ergebniszeilen und es ist nicht klar, welche zu verwenden ist.
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.

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).

Weiterhin frage ich mich, wofür loc_subtype gedacht ist. Bisher ist es ja
immer NULL.

Und welche genaue Bedeutung hat language? Was soll native_ aussagen? Könnte
man nicht überall die ISO-Notaion mit sprache oder sprache_LAND verwenden?
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".

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

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.

cu,
        boris

-- 
Dipl.-Inf. Boris Folgmann   mailto:boris-eHLBQHuAAmMb1SvskN2V4Q@xxxxxxxxxxxxxxxx
TeamForge GmbH              http://www.teamforge.de
-m-o-d-w-a-r-s-             http://www.modwars.de
-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)