logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: Doppelte Einträge in geodb_textdata: msg#00055

Subject: Re: Doppelte Einträge in geodb_textdata
Hallo Boris,

>mir ist bei der aktuellen opengeodb-0.2.1f-UTF8-postgres.gz aufgefallen,
>das es hier Einträge in geodb_textdata gibt, die sich nur in der loc_id
>unterscheiden:
>
[...]

>Ist das nicht alles redundant?

Ja, das ist "ein wenig" redundant.

Eine Normalisierung von z.B.:

'Verwaltungsgemeinschaft Laichinger Alb',500700000,'de',true,true,NULL,NULL;

waere moeglich, aber nicht wirklich sinnvoll, denke ich. Es wuerde
darauf hinauslaufen, dass wir fuer alle Daten, die jenseits des
Schemas der geodb_hierarchies liegen eine Normalisierung machen
muessten.

Sprich: Verwaltungsgemeinschaften o.ae., KFZ-Kennzeichen, Postleitzahlen,
aber auch Hoehendaten oder Einwohnerzahlen usw. usf..

Es wuerde auf eine vor geodb_[text|int|float]data vorgeschaltete
Relation hinauslaufen, die nochmal eine Beziehung aufbaut, in
einer Form wie z.B.:

loc_id           integer not null,
data_id          integer not null,
data_type        integer not null, /* text-, int- oder floatdata */
valid_since      date,
date_type_since  integer,
valid_until      date
date_type_until  integer

In geodb_*data wuerden die Datumsangaben wegfallen.

Das KANN man machen, aber ich denke, die Komplexitaet der jetzigen
Anfragen ist gross genug.

Fuer jeden Zugriff auf die geodb_*data Relationen muesste man
eine weitere Bedingung einbauen:

    ... and
    r.data_id = td.data_id and
    r.data_type = TEXTDATA ...

Der Effekt: man haette "vielleicht" einen schnelleren Zugriff, weil
die Daten "vielleicht" weniger Platz einnehmen auf der Platte. Aber
wie gesagt: "Vielleicht".

Und man haette eine potentiell eine groessere Datenkonsistenz, weil
es dann nicht mehr vorkommen kann, dass es einmal Laichlinger Alb
heisst und ein anderes mal Laichinger Alb, obwohl es eigentlich
identisch sein sollte. Dieses Argument halte ich fuer nicht so sehr
stichhaltig, weil die Datenmanipulation eh kaum noch manuell
durchfuehrbar ist in einer solchen Konstellation, so dass die
Anwendungs- / Manipulationsprogramme die Konsistenz absichern sollten.

>Oder liegt das daran, dass die loc_ids sich nicht mehr verändern dürfen,
>damit diverse Anwendungen keine Probleme bekommen?
>
Nein, nein, damit hat das nichts zu tun.

Es hat damit zu tun, dass Verwaltungsgemeinschaften (wie auch
Postleitzahlen oder KFZ-Kennzeichen) nicht in der geodb_hierarchies
oder einer vergleichbaren Relation vertreten sind.

Die geodb_hierarchies bietet fuer neun Ebenen eine Normalisierung
an, aber halt nicht fuer ALLE moeglichen Attribute.

Gruesse,
Thomas



<Prev in Thread] Current Thread [Next in Thread>