Fragen zu opengeodb (PLZ-Koordinaten, Performance, andere RDBMS)

[Hannes Streicher]

Guten Tag Lucas Mengel,

am Sonntag, 16. März 2008 um 10:20 schrieben Sie:


> Uch korrigiere: große Webseiten wie Kwick.de etc. scheinen
> doch nicht die opengeodb zu nutzen.
> Eine Abfrage im Anmeldeformular auf http://www.kwick.de 
> ergibt bei der Postleitzahl 10969 die Ergebnisse "Berlin"
> und "Berlin Kreuzberg".
> Kreuzberg ist in der opengeodb jedoch überhaupt nicht
> eingetragen.
> Hat jemand eine Ahnung, welche Datenbank die nutzen könnten?

wenn du Geld hast kriegst du die Daten unter anderem von der Post
in beliebger genauigkeit

--
Mit freundlichen Grüssen
Hannes Streicher                            mailto:HStreicher@...

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Lucas Mengel]

Ich hab mir jetzt ein Statement gebastelt, welches nach
Eingabe einer Postleitzahl die zu dieser Postleitzahl
gehördenden Koordinaten und Stadtnamen ausgibt:

SELECT
        a.text_type,
        a.text_val,
        a.loc_id,
        c.lon,
        c.lat
FROM
        geodb_textdata a,
        geodb_textdata b,
        geodb_coordinates c
WHERE
        a.text_locale = 'de' AND
        a.text_type = 500100000 AND
        b.loc_id = a.loc_id AND
        b.text_type = 500300000 AND
        b.text_val = 8000 AND
        c.loc_id = b.loc_id


die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
korrekt, aber leider unerwünscht, weil ich eigentlich nur
deutsche Ergebnisse haben will!
Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
Deutschland?

Gruß, Luke
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Preymesser]

On 16/03/2008, Lucas Mengel <froschpopo@...> wrote:

die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
korrekt, aber leider unerwünscht, weil ich eigentlich nur
deutsche Ergebnisse haben will!
Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
Deutschland?

ganz pragmatische Lösung:
indem du nur PLZen zwischen '00000' und '99999' abfragst?

-Thomas

--
Thomas Preymesser
thopre@...
Telefon: 030 - 49 78 37 06
http://thopre.wordpress.com/
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Lucas Mengel]

Dann bekomme ich, insofern es die geodb irgendwann mal
vorsieht, auch französische.
Aber mal eine andere Frage: Schweiz, Liechtenstein und
Österreich haben ja vierstellige Postleitzahlen.
Wie könnte ich diese dann deinem Vorschlag nach voneinander
unterscheiden?

Gruß,
Lucas
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Hi Lucas,

Lucas Mengel wrote:

> Ich hab mir jetzt ein Statement gebastelt, welches nach
> Eingabe einer Postleitzahl die zu dieser Postleitzahl
> gehördenden Koordinaten und Stadtnamen ausgibt:
>
> SELECT
> a.text_type,
> a.text_val,
> a.loc_id,
> c.lon,
> c.lat
> FROM
> geodb_textdata a,
> geodb_textdata b,
> geodb_coordinates c
> WHERE
> a.text_locale = 'de' AND
> a.text_type = 500100000 AND
> b.loc_id = a.loc_id AND
> b.text_type = 500300000 AND
> b.text_val = 8000 AND
> c.loc_id = b.loc_id
>
>
> die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
> korrekt, aber leider unerwünscht, weil ich eigentlich nur
> deutsche Ergebnisse haben will!
> Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
> Deutschland?

Hmmm, gute Frage. :-) Ich habe mir vor längerer Zeit mal eine Abfrage
geschnitzt, die alle Postleitzahlen von Bayern ausspuckt:

SELECT plz.loc_id as l_plz,
       plz.text_val as t_plz
FROM geodb_hierarchies hi,
     geodb_textdata land,
     geodb_textdata bundesland,
     geodb_textdata plz
WHERE hi.id_lvl2=land.loc_id AND
      land.text_val='DE' AND
      land.text_type=500100001 AND
      hi.id_lvl3=bundesland.loc_id AND
      bundesland.text_val='BY' AND
      bundesland.text_type=500100001 AND
      hi.loc_id=hi.id_lvl6 AND
      plz.loc_id=hi.loc_id AND
      plz.text_type=500300000
ORDER BY l_plz, t_plz

Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan
auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten,
da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist,
von Normalisierung keine Spur.

Möglicherweise hilft es, in deinem SQL-Statement

WHERE
        a.text_locale = 'de' AND
        a.text_type = 500100000 AND

durch

WHERE
      a.text_val='DE' AND
      a.text_type=500100001 AND

zu ersetzen.

BTW, was hieltest du davon, statt den Aliasen a, b, c "sprechende"
Aliase zu verwenden? Dann würde man bei deinem SQL-Statement eher
durchblicken ...

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Hallo Thomas,

Thomas Preymesser wrote:

> On 16/03/2008, *Lucas Mengel* <froschpopo@...
> <mailto:froschpopo@...>> wrote:

>>     die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
>>     korrekt, aber leider unerwünscht, weil ich eigentlich nur
>>     deutsche Ergebnisse haben will!
>>     Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
>>     Deutschland?

> ganz pragmatische Lösung:
> indem du nur PLZen zwischen '00000' und '99999' abfragst?

Sorry, aber wenn ich so einen Krampf lese, dann springt mir das Messer
in der Hosentasche auf!

Die Lösung, die du da vorschlägst, hat nichts mit programmieren zu tun,
das ist Gefrickel aus der alleruntersten Schublade!

Das erinnert mich an manche Pappnasen aus dem vorigen Jahrhundert, die
aus einer vierstelligen Jahreszahl eine zweistellige gemacht haben,
indem sie 1900 subtrahiert haben (sic!). Die richtige Lösung
(selbstverständlich Jahr-2000-fest) wäre modulo 100 gewesen.
Wenn man heute irgendwo in einer Anwendung das Jahr 108 als das aktuelle
angezeigt bekommt, dann war genau so eine Pappnase am Werk ...

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Müller-3]

Hallo zusammen,

ich kann da nur auf mein Posting "Konzept so noch zeit gemäß ?" verweisen -
genau das kommt dabei heraus wenn Anwender mit den Daten überfordert sind.

Gruß,
Andreas

--
+--------------------------------------------------+
| Nur zwei Dinge sind unendlich:                   |
| Das Weltall und die menschliche Dummheit.        |
| Beim Weltall bin ich mir aber nicht ganz sicher. |
|                                                  |
| ~Albert Einstein~                                |
+--------------------------------------------------+
 

> -----Original Message-----
> From: opengeodb-bounces@...
> [mailto:opengeodb-bounces@...] On Behalf Of Robert Böck
> Sent: Sunday, March 16, 2008 6:48 PM
> To: opengeodb@...
> Subject: Re: [opengeodb] nur deutschland
>
> Hallo Thomas,
>
> Thomas Preymesser wrote:
>
> > On 16/03/2008, *Lucas Mengel* <froschpopo@...
> > <mailto:froschpopo@...>> wrote:
>
> >>     die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
> >>     korrekt, aber leider unerwünscht, weil ich eigentlich nur
> >>     deutsche Ergebnisse haben will!
> >>     Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
> >>     Deutschland?
>
> > ganz pragmatische Lösung:
> > indem du nur PLZen zwischen '00000' und '99999' abfragst?
>
> Sorry, aber wenn ich so einen Krampf lese, dann springt mir das Messer
> in der Hosentasche auf!
>
> Die Lösung, die du da vorschlägst, hat nichts mit
> programmieren zu tun,
> das ist Gefrickel aus der alleruntersten Schublade!
>
> Das erinnert mich an manche Pappnasen aus dem vorigen Jahrhundert, die
> aus einer vierstelligen Jahreszahl eine zweistellige gemacht haben,
> indem sie 1900 subtrahiert haben (sic!). Die richtige Lösung
> (selbstverständlich Jahr-2000-fest) wäre modulo 100 gewesen.
> Wenn man heute irgendwo in einer Anwendung das Jahr 108 als
> das aktuelle
> angezeigt bekommt, dann war genau so eine Pappnase am Werk ...
>
> cu, Robo :)
>
> --
> Mailingliste OpenGeoDB
> Listenadresse: opengeodb@...
> Informationen: http://opengeodb.de
> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Lucas Mengel wrote:
>
> die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
> korrekt, aber leider unerwünscht, weil ich eigentlich nur
> deutsche Ergebnisse haben will!
> Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
> Deutschland?

Du solltest eben Merkmale verwenden, die gezielt auf Deutschland abheben:

- verwende nur den deutschen Datenbestand (D.sql)

- verwende die hierarchies - die stehen separat zur Verfügung
        http://fa-technik.adfc.de/code/opengeodb/dump/Dhier.sql

- erzeuge dir die hierachies oder andere Markierungen selbst ueber die
"Teil-von"-Beziehungen

Drei verschiedene Ansaetze, die alle zum Erfolg fuehren koennen und alle
auf der Information aufbauen, dass ein Eintrag zu Deutschland gehoert.

Die Frage wurde hier aber schon mehrfach gestellt - eine Suche in den
Archiven mag helfen.

Schoenen Gruss
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo,

> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan
> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten,
> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist,
> von Normalisierung keine Spur.

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?

Ich habe im Gegensatz dazu den Eindruck, dass vielen Nutzern hier die
Normalisierung zu weit geht. Martin hat schon mehrfach dargelegt, dass
eine vereinfachte (und somit denormalisierte) Struktur nicht in der Lage
ist, alle möglichen Abhängigkeiten aufzunehmen, und auch ein Blick ins
Mailinglisten-Archiv erhellt vielleicht den einen oder anderen Aspekt,
warum die Daten so organisiert sind, wie sie sind.

Für die meisten Nutzer ist die Opengeodb sicherlich hauptsächlich für
die Implementierung einer Umkreissuche auf PLZ-Basis interessant und für
diesen Zweck ist es sicherlich sinnvoll, sich die dafür relevanten
Informationen aus der Datenbank zu extrahieren. Ich denke für diejenigen
sollte es kein Problem darstellen, sich ein Skript zu erstellen, das die
jetzigen Datenbank in eine ihm genehme Struktur überführt.

Aber auch hier gilt: Machen statt Meckern. Wer dem Projekt helfen will,
sollte so etwas implementieren und der Allgemeinheit zur Verfügung
stellen, und nicht erwarten, dass alles für die eigenen Bedürfnisse
bereit steht. Die Behauptung, die Datenbankstruktur wäre ein "Saustall"
ohne Belege dafür oder eine Alternative zu präsentieren, finde ich
ehrlich gesagt etwas unverfroren, zumal ich den Eindruck habe, Du hast
sie lediglich nicht verstanden. Die jetzige Struktur bietet die maximale
Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren
kann, und das sollte meiner Meinung nach auch so bleiben!

Und wer tatsächlich meint, er hätte einen besseren Entwurf für die
Datenbank-Struktur der alle Anforderungen erfüllt: Einfach hier
veröffentlichen und zur Diskussion stellen.

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Preymesser]

On 16/03/2008, Robert Böck <robert.boeck@...> wrote:

Hallo Thomas,


Thomas Preymesser wrote:

> On 16/03/2008, *Lucas Mengel* <froschpopo@...

> <mailto:froschpopo@...>> wrote:

>>     die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch
>>     korrekt, aber leider unerwünscht, weil ich eigentlich nur
>>     deutsche Ergebnisse haben will!
>>     Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
>>     Deutschland?

> ganz pragmatische Lösung:
> indem du nur PLZen zwischen '00000' und '99999' abfragst?


Sorry, aber wenn ich so einen Krampf lese, dann springt mir das Messer
in der Hosentasche auf!

Die Lösung, die du da vorschlägst, hat nichts mit programmieren zu tun,
das ist Gefrickel aus der alleruntersten Schublade!

welchen Teil von "pragmatisch" hast  du nicht verstanden?

Lucas hat gefragt, wie er es verhindern kann, daß er nicht-Deutschland  Orte erhält, wenn er eine PLZ abfragt, die in Deutschland überhaupt nicht existiert. Ich habe  daraufhin geantwortet, daß er nur PLZen abfragen soll, die in Deutschland möglich sind.
Daß das keine Abfrage auf ein beliebiges Land ist, ist mir völlig klar - aber das war ja auch nicht die ursprüngliche Frage.

-Thomas

--
Thomas Preymesser
thopre@...
Telefon: 030 - 49 78 37 06
http://thopre.wordpress.com/
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Hallo Thomas,

Thomas Preymesser wrote:

>     >>     Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf
>     >>     Deutschland?
>
>     > ganz pragmatische Lösung:
>     > indem du nur PLZen zwischen '00000' und '99999' abfragst?
>
>
>     Sorry, aber wenn ich so einen Krampf lese, dann springt mir das Messer
>     in der Hosentasche auf!
>
>     Die Lösung, die du da vorschlägst, hat nichts mit programmieren zu tun,
>     das ist Gefrickel aus der alleruntersten Schublade!
>
>
> welchen Teil von "pragmatisch" hast  du nicht verstanden?

Du verwechselst "pragmatisch" mit "Gefrickel".

> Lucas hat gefragt, wie er es verhindern kann, daß er nicht-Deutschland
> Orte erhält, wenn er eine PLZ abfragt, die in Deutschland überhaupt
> nicht existiert. Ich habe  daraufhin geantwortet, daß er nur PLZen
> abfragen soll, die in Deutschland möglich sind.
> Daß das keine Abfrage auf ein beliebiges Land ist, ist mir völlig klar -
> aber das war ja auch nicht die ursprüngliche Frage.

Und genau das ist dein Problem. Nimm mal deine Scheuklappen ab und sieh
über den Tellerrand deines begrenzten Horizontes hinaus. Mit dem Muster,
mit dem du Postleitzahlen erkennen willst, die nur in Deutschland
möglich sind, erkennst du auch Postleitzahlen, die in anderen Ländern
möglich sind.

Wenn man das von dir vorgeschlagene Gefrickel verwendet, gibt es
spätestens dann einen ganz gewaltigen Knall, wenn die Opengeodb auf
weitere Länder erweitert sind, die Postleitzahlen haben, die genauso
aussehen, wie die in Deutschland.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Lucas Mengel]

Ich habe hier schon mehrfach dafür plädiert, dass opengeodb
sich mehr seinem Ursprung widmet, nämlich die Sammlung und
publizierung geotypischer Informationen, und die
Verwendungsarchitektur dem Nutzer überlässt!
Wir dürfen ja auch nie vergessen, dass besonders ältere
Menschen großes Interesse an solchen Datenbanken haben! Das
moderne Großvaterhobby ist es, im Internet Datenbanken über
Modelleisenbahn, Bäume, Edelsteine und Geodaten zu pflegen.
Man darf auch niemals vergessen, dass gerade solche Menschen
sehr wichtig sind, denn sie haben Zeit und Interesse.
Der aktuelle Stand ist jedoch der, dass die opengeodb primär
durch ein dominantes Datenbankmodell auffällt das dem
einzelnen Nutzer förmlich eine Verwendungsstruktur aufdränkt.
Hier sind kompetente Leute anwesend, die sowieso die
Datenbank ihren eigenen Bedürfnissen anpassen werden.
Es kann doch nicht angehen, dass eine riesige Flirtcommunity
sich komplett neu ausrichten muss, nur weil die opengeodb
den Machern eigene Vorstellungen aufzwingt!

Gruß,
Lucas

Stephan S schrieb:

> Hallo,
>
>> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan
>> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten,
>> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist,
>> von Normalisierung keine Spur.
>
> 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?
>
> Ich habe im Gegensatz dazu den Eindruck, dass vielen Nutzern hier die
> Normalisierung zu weit geht. Martin hat schon mehrfach dargelegt, dass
> eine vereinfachte (und somit denormalisierte) Struktur nicht in der Lage
> ist, alle möglichen Abhängigkeiten aufzunehmen, und auch ein Blick ins
> Mailinglisten-Archiv erhellt vielleicht den einen oder anderen Aspekt,
> warum die Daten so organisiert sind, wie sie sind.
>
> Für die meisten Nutzer ist die Opengeodb sicherlich hauptsächlich für
> die Implementierung einer Umkreissuche auf PLZ-Basis interessant und für
> diesen Zweck ist es sicherlich sinnvoll, sich die dafür relevanten
> Informationen aus der Datenbank zu extrahieren. Ich denke für diejenigen
> sollte es kein Problem darstellen, sich ein Skript zu erstellen, das die
> jetzigen Datenbank in eine ihm genehme Struktur überführt.
>
> Aber auch hier gilt: Machen statt Meckern. Wer dem Projekt helfen will,
> sollte so etwas implementieren und der Allgemeinheit zur Verfügung
> stellen, und nicht erwarten, dass alles für die eigenen Bedürfnisse
> bereit steht. Die Behauptung, die Datenbankstruktur wäre ein "Saustall"
> ohne Belege dafür oder eine Alternative zu präsentieren, finde ich
> ehrlich gesagt etwas unverfroren, zumal ich den Eindruck habe, Du hast
> sie lediglich nicht verstanden. Die jetzige Struktur bietet die maximale
> Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren
> kann, und das sollte meiner Meinung nach auch so bleiben!
>
> Und wer tatsächlich meint, er hätte einen besseren Entwurf für die
> Datenbank-Struktur der alle Anforderungen erfüllt: Einfach hier
> veröffentlichen und zur Diskussion stellen.
>
> Gruß
> Stephan
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Stephan S wrote:

>> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan
>> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten,
>> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist,
>> von Normalisierung keine Spur.

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

> Für die meisten Nutzer ist die Opengeodb sicherlich hauptsächlich für
> die Implementierung einer Umkreissuche auf PLZ-Basis interessant und für
> diesen Zweck ist es sicherlich sinnvoll, sich die dafür relevanten
> Informationen aus der Datenbank zu extrahieren. Ich denke für diejenigen
> sollte es kein Problem darstellen, sich ein Skript zu erstellen, das die
> jetzigen Datenbank in eine ihm genehme Struktur überführt.

Und genau so ein Script habe ich mir mal gebaut.

> Aber auch hier gilt: Machen statt Meckern. Wer dem Projekt helfen will,
> sollte so etwas implementieren und der Allgemeinheit zur Verfügung
> stellen, und nicht erwarten, dass alles für die eigenen Bedürfnisse
> bereit steht.

Mein Script extrahiert nur einen Teilbereich der Daten, und die
Datenstruktur hierfür ist genau auf diesen Teilbereich zugeschnitten und
nicht für die Opengeodb als Ganzes tauglich.

> Die Behauptung, die Datenbankstruktur wäre ein "Saustall"
> ohne Belege dafür oder eine Alternative zu präsentieren, finde ich
> ehrlich gesagt etwas unverfroren,

Du willst allen Ernstes behaupten, Kritik wäre nur zulässig, wenn man
gleichzeitig eine Alternative für das kritisierte Objekt anbietet?

> zumal ich den Eindruck habe, Du hast sie lediglich nicht verstanden.

Zugegebenermaßen habe ich einige Zeit gebraucht, um die
Datenbankstruktur zu verstehen.

Ich habe jedoch den Eindruck, dass derjenige, der die Datenbankstruktur
entworfen hat, noch nicht mal wusste, dass so etwas wie Normalisierung
überhaupt existiert.

> Die jetzige Struktur bietet die maximale
> Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren
> kann, und das sollte meiner Meinung nach auch so bleiben!

Flexibility through obscurity?

> Und wer tatsächlich meint, er hätte einen besseren Entwurf für die
> Datenbank-Struktur der alle Anforderungen erfüllt: Einfach hier
> veröffentlichen und zur Diskussion stellen.

Nö, habe ich nicht, und das habe ich auch nie behauptet.

Trotzdem nehme ich mir das Recht heraus, Kritik zu üben.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Robert Böck wrote:

> Stephan S wrote:
>
>>> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan
>>> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten,
>>> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist,
>>> von Normalisierung keine Spur.
>
>> 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?

Und wie sähe sie als konkretes Beispiel aus?

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

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)

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). Ich bin mir
ziemlich sicher, dass man die Performance auch deutlich verbessern
würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden.

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

Die check-Constraints habe ich mal weggelassen, damit es übersichtlicher
ist.

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

Dann ist da alles mögliche drin, was gar nicht zusammengehört (also
Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer,
Regiertungsbezirke, etc.) Die Tabelle enthält Daten (text_val) und
Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut
und Rüben.

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.

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.

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

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Hallo Lucas.

Lucas Mengel schrieb:
> Es kann doch nicht angehen, dass eine riesige Flirtcommunity
> sich komplett neu ausrichten muss, nur weil die opengeodb
> den Machern eigene Vorstellungen aufzwingt!
>  
An soweit ich weiß KEINER Stelle verspricht die Opengeodb irgendeine
Anwendungsmöglichkeit direkt aus den bereitgestellten Daten heraus.

Wenn sich hier jemand dazu zwingen lässt, sein Angebot wegen der
opengeodb neu auszurichten, der sollte sich überlegen, ob er nicht als
Hobby lieber Briefmarken sammeln bzw. beruflich ins Sekretariat wechseln
will (Achtung: das heißt nicht, dass Programmierer im Sekretariat gut
aufgehoben sind, wenn ich mir Kommilitonen von mir und andere so angucke!).
Die OpenGeoDB birgt unheimlich viele Daten und veröffentlicht diese zur
Zeit in einer Struktur, die für wenige Zwecke optimiert ist, zu denen
eben nicht PLZ-Abfragen oder ähnliches gehören.
Es ist und bleibt Aufgabe des Programmierers einer Anwendung, sich zu
überlegen, was für Daten er braucht, wie er sie organisiert und woher er
sie bekommt.
Wenn dies eben einen Portierungsaufwand bedeutet, dann ist das eben so.

An Martins Stelle würde ich (und ja, ich selbst verwende auch SQL) bei
zu viel Beschwerden auch überlegen, wieder bei reinen tab-Formaten zu
bleiben. Wer damit nichts anfangen kann, sollte die Finger davon lassen.

Gruß
Peter Wendorff
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

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

Das ist eine Behauptung. Wo ist ein Beleg oder ein Beispiel? Welches
Attribut enthält Deiner Meinung nach einen nichtatomaren Wertebereich?

[...]
> > Die Behauptung, die Datenbankstruktur wäre ein "Saustall"
> > ohne Belege dafür oder eine Alternative zu präsentieren, finde ich
> > ehrlich gesagt etwas unverfroren,
>
> Du willst allen Ernstes behaupten, Kritik wäre nur zulässig, wenn man
> gleichzeitig eine Alternative für das kritisierte Objekt anbietet?

Nein, wenn Du nochmal genau liest, steht da, dass ich bei der Äußerung
von Kritik in einer derart harschen Form, Belege für die aufgestellten
Behauptungen oder zumindest einen Alternativ-Entwurf erwarte, denn das
würde zeigen, dass du dich mit dem Gegenstand deiner Kritik auseinander
gesetzt hast. Fundierte Kritik ist sehr willkommen, unreflektierte
Schmähungen und Worthülsen nicht.

[...]
> Ich habe jedoch den Eindruck, dass derjenige, der die Datenbankstruktur
> entworfen hat, noch nicht mal wusste, dass so etwas wie Normalisierung
> überhaupt existiert.

Zum einen habe ich den Eindruck, du hast dir nicht die Mühe gemacht das
Mailinglisten-Archiv zu bemühen und die diesbezüglichen Mails zu lesen.
OK, wäre auch etwas Arbeit.

Weiterhin erwecken deine Äußerungen den Eindruck, dass du dich mal
-ähnlich oberflächlich wie mit der opengeodb- mit Datenbank-Normalisierung
beschäftigt hast und bei jeder Gelegenheit damit um dich wirfst.
Normalisierung ist ein Konzept zur Vermeidung von Redundanzen und
Inkonsistenzen, keine Religion.

Wikipedia zitieren ist eines, die Inhalte lesen und verstehen etwas
anderes.

Zum dritten habe ich den Eindruck, dass Du dir noch immer nicht die Mühe
gemacht hast, zu ergründen warum die Struktur so ist wie sie ist. Beim
Entwickeln einer alternativen Struktur, die Art und Umfang der
Information aufnehmen kann, die die opengeodb bietet hättest Du schnell
gemerkt, dass eine "vereinfachte" Form wie sie dir vorschwebt dies nicht
leisten kann. Versuche einfach mal in deiner vereinfachten Form die
verschiedenen Hierarchie-Ebenen in unterschiedlichen Staaten oder
Bundesländern abzubilden.

> > Die jetzige Struktur bietet die maximale
> > Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren
> > kann, und das sollte meiner Meinung nach auch so bleiben!
>
> Flexibility through obscurity?

Du verwechselst hier Ursache und Auswirkung, die Flexibilität wird nicht
durch Unverständlichkeit erreicht. Dir erscheint es unverständlich, weil
die Flexibilität einen höheren Abstraktionsgrad erzwingt. Wenn du aber
glaubst, es gibt ein leichter verständliches Modell, das die gleiche
Flexibilität bietet, dann ist hier jeder froh darüber. Immer her damit.

Vielleicht solltest Du die Ratschläge, die du anderen gibst auch selbst
beherzigen:
<zitat>
|Und genau das ist dein Problem. Nimm mal deine Scheuklappen ab und sieh
|über den Tellerrand deines begrenzten Horizontes hinaus.
</zitat>

[...]
> Nö, habe ich nicht, und das habe ich auch nie behauptet.
> Trotzdem nehme ich mir das Recht heraus, Kritik zu üben.

Das sei dir unbenommen, aber wenn Deine Kritik gehört und beachtet
werden soll, sollte sie auch mit irgendetwas untermauert sein.

Du mißverstehst die Motivation hinter opengeodb, hier werden Geodaten
gesammelt, bearbeitet und zur Verfügung gestellt. Und dafür ist die
bestehende Datenbank-Struktur entwickelt worden. Du willst die Struktur
auf Deinen eingeschränkten Bedarf (Webanwendung o.ä.) hin optimieren,
das kannst Du gerne für dich tun. Für eine Umkreissuche ist das
bestehende Datenbankmodell sicherlich absolut ungeeignet und
unperformant, da hast Du recht. Und deshalb ist jedem angeraten (wie
hier schon hundertmal erwähnt wurde) sich die benötigten Informationen
zu extrahieren und in eine für seinen Zweck passende Struktur zu
überführen. Das kann und will die opengeodb nicht leisten.

Du scheinst das ja -wie etliche vor dir- bereits erfolgreich
durchgeführt zu haben, also wo liegt dein Problem?

Niemand hier glaubt, dass die Opengeodb in der jetzigen Form perfekt ist
und jeder der helfen will sie zu verbessern ist hier gern gesehen. Dazu
gehört aber die Bereitschaft etwas mehr einzubringen, als ein paar
abwertende Statements.

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Lucas,

> Es kann doch nicht angehen, dass eine riesige Flirtcommunity
> sich komplett neu ausrichten muss, nur weil die opengeodb
> den Machern eigene Vorstellungen aufzwingt!

Kann es denn angehen, dass die opengeodb sich neu ausrichten soll, weil
eine Flirtcommunity deren Daten nutzen will? Wer zwingt die
Flirtcommunitiy sich irgendwie auszurichten? Wer will denn hier was von
wem?

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Martin Trautmann wrote:r

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

Da möchte ich mich jetzt nicht festlegen.

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

In der Praxis werden sich für Abfragen weniger Bezüge ergeben, eben weil
nicht alles in eine Tabelle reingestopft ist und somit schon die Bezüge
für die Datenart (text_type) wegfallen.

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

Wenn man das, was jetzt in geodb_textdata drinsteckt,
auseinanderklamüsert, dann reduziert es einerseits die Datenmenge, weil
text_type wegfallen kann, andererseits vereinfacht es die Abfragen, weil
ich keinen text_type dafür herziehen muss, nur um festzulegen, welche
Art von Daten (PLZ, Ort, etc.) ich haben will.

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

Weil die loc_id in der Tabelle geodb_locations der Primärschlüssel ist.
Wenn ich nun geodb_locations.loc_id mit geodb_textdata.loc_id verknüpfe,
folgt daraus, dass geodb_textdata.loc_id ein Fremdschlüssel ist.

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

Genauso wie Äpfel, Birnen und Tomaten nicht zusammengehören. Die gehören
auch in getrennte Kisten.

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

Meiner Meinung nach schon. Weil text_type redundant ist. Wenn man das
alles sinnvoll zerlegt, wird text_type überflüssig.

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

Ein Integer. Steht doch da.

> Woher weiss nun ein Ort, welche PLZ zu ihm gehoert?

Indem er mit der PLZ verknüpft wird.

> Woher weiss die PLZ, seit wann sie gueltig ist?

Wenn sie das wissen muss, kann man ihr diese Information ja noch mitgeben.

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

Das muss die PLZ doch gar nicht wissen, weil das in einer anderen
Relation drinsteht.

> Was soll dieses einsame Atom, so ganz allein ohne Molekülverbindungen?
> Langweilt es sich dann nicht?

Mit den ganzen anderen Relationen sicher 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?

Ja selbstverständlich. Weil in jeder "Kiste" nur noch gleichartige
"Atome" drin sind. Das spart Metadaten und somit Platz, ist
verständlicher und erhöht auch die Geschwindigkeit, weil ich keine
Metadaten mehr heranziehen muss, um zu wissen, mit was für einer Art von
Daten ich es überhaupt zu tun habe.

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

Nein, JETZT ist es kompliziert, weil verschiedenartige Daten in einer
Tabelle drinstecken und ich zusätzliche Verknüpfungen brauche, um
festzulegen, welche Art von Daten ich zur Abfrage heranziehen will.

> Wer das zur Performance-Optimierung
> braucht, der sollte diese IMHO selbst anlegen - denn für mich sieht das
> nach redundanten Daten aus.

Mitnichten. Eine vernünftige, normalisierte Datenstruktur vermeidet ja
gerade Redundanzen.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)