[opengeodb] nur deutschland

[Martin Trautmann]

Robert Böck wrote:
> Martin Trautmann wrote:
>> Robert Böck wrote:
>>> Stephan S wrote:
>>>
>>>> Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur
>>>> wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen
>>>> welche Normalform Deiner Meinung nach verstoßen wird?
>>> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
>> Was würde eine Normalisierung für praktische Vorteile mit sich bringen?
>> Wofür braucht man sie, was hilft sie?
>
> Kann man sehr schön bei Wikipedia nachlesen:
>
> http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

Aha - und welche Normalform willst du?

> Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements,
> um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt
> sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten,
> um der Datenbank bestimmte Datensätze zu entlocken).

fuer bestimmte ja - aber gerade normalisiert ergeben sich 
moeglicherweise mehr Bezuege als wenn man alles in eine einzige Tabelle 
reinpfropft.

> Ich bin mir
> ziemlich sicher, dass man die Performance auch deutlich verbessern
> würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden.

Ich bin mir sicher, dass man Performance dann verbessern kann, wenn man 
rauswirft, was man nicht braucht und Hilfstabellen dafuer anlegt, was 
man haeufig braucht.

Das eine verringert die Datenmenge, das andere vergroessert sie.

>> Und wie sähe sie als konkretes Beispiel aus?
>
> Nehmen wir mal die bereits erwähnte geodb_textdata:
>
> create table geodb_textdata (
>    loc_id               integer not null references geodb_locations,
>    text_val             varchar(255) not null,
>    text_type            integer not null,
>    text_locale          varchar(5),
>    is_native_lang       smallint(1),
>    is_default_name      smallint(1),
>    valid_since          date,
>    date_type_since      integer,
>    valid_until          date not null,
>    date_type_until      integer not null,
> ) TYPE=InnoDB CHARACTER SET utf8;


> Es geht schon mal damit los, dass die Tabelle keinen primary key hat.
> loc_id ist ein foreign key.

Wie kommst du darauf, die loc_id waere kein primary key? Sie wird also 
solcher verwendet.

> Dann ist da alles mögliche drin, was gar nicht zusammengehört (also
> Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer,
> Regiertungsbezirke, etc.)

Das gehoert nicht zusammen, glaubst du? Seltsam.


> Die Tabelle enthält Daten (text_val) und
> Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut
> und Rüben.

Das hat mit Normalisierung aber wohl nichts mehr zu tun?

> Und nun zu einem konkreten Beispiel. Ich greife mal die Postleitzahlen
> heraus:
>
> create table geodb_plz (
>    id    integer not null primary key,
>    plz   varchar(255) not null
> );
>
> Das nenne ich atomar.

Und was ist deine id? Woher weiss nun ein Ort, welche PLZ zu ihm 
gehoert? Woher weiss die PLZ, seit wann sie gueltig ist? Woher weiss die 
PLZ, ob das nun zu einem einzigen Ort gehoert, zu welchen seiner 
Ortsteile, zu welchen anderen Orten, zu welchem PLZ-Gebiet, zu welchen 
Koordinaten?

Was soll dieses einsame Atom, so ganz allein ohne Molekülverbindungen? 
Langweilt es sich dann nicht?
>
> Für andere Daten muss das entsprechend gemacht werden. Und dann braucht
> man eben Tabellen, die die Relationen herstellen, z. B. zwischen einer
> PLZ und einem Ort, oder zwischen einer PLZ und einer Koordinate, etc.

Ah, du willst die Atome über Tabellen verbinden, statt die Atome gleich 
in der Tabelle drin zu haben - und das spart Platz, ist verständlicher 
und erhöht die Geschwindigkeit?

> Selbstverständlich erfordert das einiges an Gehirnschmalz und Zeit, eine
> entsprechende Datenstruktur zu definieren.

Im Moment sehe ich nur eine Verkomplizierung, weil weitere Tabellen zur 
Verknüpfung erforderlich sind. Wer das zur Performance-Optimierung 
braucht, der sollte diese IMHO selbst anlegen - denn für mich sieht das 
nach redundanten Daten aus.

Schönen Gruß
Martin