[opengeodb] nur deutschland

Stephan Schuster stephan.s at gmx.net
Fre Mar 21 15:03:17 CET 2008


 Hallo Robo,
> 
> Stephan Schuster wrote:
> 
> >> Das ändert aber nichts daran, dass geodb_textdata.text_type redundant
> >> ist. Jedenfalls meiner Auffassung nach.
> > 
> > ??? Fremdschlüssel sind nahezu immer redundant vorhanden, das liegt in
> > der Natur der Sache.
> 
> Fremdschlüssel?
> 
> Ein Feld, das mit einer Konstante verglichen wird, ist dann auf einmal
> ein Fremdschlüssel?

Falls Du dich auf die constants.txt beziehst, die früher die Bedeutung
des text_type definiert hat: Diese ist mittlerweile durch die Tabelle
geodb_type_names ersetzt worden. Falls diese bei dir nicht existiert,
könnte dir das bereits die Schwierigkeiten verdeutlichen, die Änderungen
in der Datenbank-Struktur mit sich bringen. Wenn ich mich noch einmal
kurz selbst zitieren darf (das hätte dir den Zusammenhang verdeutlichen
sollen, falls Du versuchst zu verstehen was ich schreibe):

| Wenn Du möchtest, kannst Du geodb_textdata.text_type auch als
| Fremdschlüssel aus der Tabelle geodb_type_names sehen, das kommt deinem
| Verständnis von Datenbank-Modellen und Normalisierung sicher näher.

[...]
> >> > Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!
> >> 
> >> Wer behauptet das?
> > 
> > Du. Hier:
> >>> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
> >  Du hast dich sogar selbst zitiert. Einen Beleg hast Du noch nicht
> >  geliefert...
> 
> text_type != geodb_textdata

Relation != Attribut
Lies mal den Artikel den Du aus der Wikipedia angeführt hast und
beantworte die Frage, wie eine Relation atomar sein soll. Dann prüfst Du
die Attribute der Relation geodb_textdata und erklärst welches nicht
atomar ist. Das Ergebnis deiner Prüfung teilst Du uns dann bitte mit. 
Oder du führst mal ein Beispiel an, was deiner Meinung nach nicht atomar
ist...
 
> [opengeodb 0.1.3]
> >> Und auch wenn es dir wahrscheinlich nicht gefällt, muss ich sagen, dass
> >> die Tabelle geodb_locations hochgradig redundante Daten enthält. Was
> >> soll bitte daran normalisiert sein, wenn immer wieder "Landkreis xyz"
> >> drinsteht? Die Landkreise gehören in eine eigene Tabelle und über
> >> Fremdschlüssel in der geodb_locations referenziert. Und nicht nur die
> >> Landkreise.
> > 
> > Wieder eine Behauptung, ohne  Beleg oder Beispiel. Wo steht immer wieder
> > ""Landkreis xyz"?
> 
> "Landkreis Ostallgäu" kommt z. B. so ziemlich genau 45 mal vor ...
> 
> > Konkret:
> > 
> > SELECT DISTINCT *
> > FROM geodb_locations
> > WHERE loc_type =100500000
> 
> loc_type? Wo bitte gibt es bei der 0.1.3 einen loc_type?
>
> Ich darf daran erinnern, dass du die 0.1.3 ins Gespräch gebracht hast!

Nein, ich habe dir angeboten, dir einen Dump der 0.1.3 zu schicken,
damit du vergleichen kannst, wie unzureichend die Daten darin abgebildet
sind. 

Willst Du damit sagen, Du wolltest mir erklären, dass die Struktur der
0.1.3 schlecht ist? Da stimmen wir absolut überein, allerdings ist mir
wirklich schleierhaft, wie Du aus dem (ich zitiere nochmal) Absatz

|Die jetzige Struktur ist aus der Erkenntnis entstanden, dass die, die du
|favorisierst, den anfallenden Daten nicht gerecht wird, denn eine solche
|Struktur war ursprünglich vorhanden. Ich schick Dir gerne mal einen Dump
|der opengeodb 0.1.3. Und ich kann dir versichern dass Normalisierung
|bei der Entwicklung der jetzigen Struktur auch ein großes Thema war. Und
|wenn du wieder behaupten willst, das Schema wäre nicht normalisiert,
|bring Belege, wenn du weiter ernst genommen werden willst.

schließt, dass sich meine Aussagen auf die 0.1.3 beziehen...
Falls es dir entgangen ist: wir diskutieren hier stets auf Grundlage der
aktuellen Datenbank-Struktur, die Martin dankenswerterweise unter
http://fa-technik.adfc.de/code/opengeodb/ bereitstellt.

[...]
> Ich wollte lediglich verdeutlichen, dass eine Sache zu verstehen nicht
> unbedingt etwas mit der Bereitschaft zu lernen zu tun hat.

Muss man hier alle Selbstverständlichkeiten durchkauen? Man benötigt die
Fähigkeit und die Bereitschaft sich mit dem Datenbank-Schema und der
Organisation von Geodaten auseinander zu setzen. Wer eines von beiden
nicht mitbringt, sollte sich einfach überlegen, ob es nicht Hobbies gibt
die seinen Fähigkeiten oder Kenntnissen besser entsprechen.

Gruß
Stephan