[opengeodb] SQL und andere Grundsätze

[Martin Trautmann]

Lucas Mengel wrote:
> Nebenbei: Was habt ihr eigentlich gegen SQL?

Überhaupt nichts - aber ich habe einen Web-Anbieter, der mit kein SQL 
anbietet und ich habe Anwendungen, für die ich kein SQL brauche.

> SQL ist die Standard-Abfrage-Sprache für Datenbanken. Das hat eigentlich 
> nichts mit Struktur oder so zu tun.

Nur weil "Standard" in der Abkürzung drinsteckt heisst das nicht, dass 
man es für alles brauchen würde.

Meine eigene Hauptanwendung ist der Code-Generator 
fa-technik.adfc.de/code/ein, mit dem man sich aus zwei Millionen 
Strassen nach Möglichkeit jede Wohnadresse in Deutschland in den 
persönlichen EIN-Code zur Wertsachencodierung umwandeln lassen kann.

Die Menge der Strassen ist noch recht gering - für so kleine Mengen 
taugen Textdateien recht gut. Schwieriger ist dort, wie man die Daten 
aufbereiten und zusammensetzen kann. Der Anwender soll es möglichst 
einfach haben, bei der Suche nach Schloßstraße, Schlossstr., 
Schloss-Straße, schlosstr usw. die richtige Antwort zu bekommen.


> In der Praxis ist die Anwendung fast immer identisch:
> User geben über ein Web-Interface ihre Postleitzahl an, woraufhin in 
> einem für sie reservierten Datensatz die Koordinaten und
> weitere Informationen aus der openGeoDB gespeichert werden.
> 
> Nun das entscheidende: Damit später eine wirklich effiziente 
> Umkreissuche entstehen kann müssen die Koordinaten in der
> User-Datenbank der jeweiligen Community/Anwendung gespeichert werden.
> Ich glaube kaum, dass irgendeine dieser Plattformen bei jeder 
> Suchanfrage dieses beknackte Ebenen-Modull durchläuft.

Dieses Ebenenmodul sollte auch nur ein einziges Mal benötigt werden. Am 
einfachsten würden die entsprechenden Befehle direkt in den SQL-Dump 
eingebaut. Beim Einlesen der SQL-Daten würden die entsprechenden 
Tabellen dann automatisch angelegt.

Wenn SQL so leistungsfähig und standardisiert ist, wie du und ich 
glauben, dann sollte das eine einfache Geschichte sein. In meiner 
eigenen Datenbank hätte ich in wenigen Minuten ein rekursives Script 
zusammengeschrieben, das die Hierarchien erzeugt haben könnte. Meine 
Anwendung arbeitet aber nur auf Teilbeständen (ich habe die Länder nach 
Tabellen getrennt, weil ich selbst nur Deutschland brauche), ist hier 
also wenig geeignet.

Ich bin mir sicher, dass ich auch auf Basis der Textdateien mit perl 
recht einfach ein Script schreiben könnte, das die Hierarchies erzeugt - 
aber genau das ist eine Funktion, die nach meinem Glauben in eine 
relationale Datenbank selbst hineingehört.

Ansonsten zum Standard von SQL: Meine Datenbank ist angeblich in der 
Lage, SQL-Anfragen zu beantworten. Mir ist das ziemlich egal - meine 
Datenbank ist zu dämlich, .sql als Import-Format zu verwenden. Auch 
OpenOffice scheint mit einer Datenbank daherzukommen. Das scheint aber 
auch nur SQL-Anfragen beantworten zu können. Wie man die .sql-Daten 
hineinbekommen würde, keine Ahnung.

Früher pflegte Thomas auch etliche verschiedene .sql-Varianten für 
Postgres, MySQL usw. - bei einem echten Standard sollte das nicht nötig 
sein.

Mein Standard sind daher die .txt-Dateien - die lassen sich mit jedem 
Texteditor verarbeiten, in fast jede Tabellenkalkulation importieren und 
taugen als Austauschformat für fast jede einfacher gestrickte Datenbank. 
Es gibt nur wenige Anwender, schätze ich, die tatsächlich von dem 
profitieren, was opengeodb so unübersichtlich zu machen scheint: 
Versionierung, Sprachvarianten usw.

> Ganz im Gegenteil: Die Betreiber solcher Seiten zerlegen die openGeoDB 
> in ihre Einzelteile und zwar solang, bis sie exakt ihrem
> Anspruch entspricht.

Für eine schlichte Umkreissuche, was wohl die Hauptanwendunger der 
opengeodb zu sein scheint, kann man natürlich auch SQL hernehmen. Ich 
vermute, von der Performance ist meine Umkreissuche effizienter, die ich 
für fa-technik.adfc.de/code/anbieter einsetze

> Ich bin nach wie vor der Meinung, man sollte einfach eine einzelne 
> SQL-Tabelle ausliefern und den Rest den Leuten überlassen.
> Darunter sind hochbezahlte und qualifizierte Programmmierer, die dem 
> jeweiligen Betreiber eine maßgeschneiderte Lösung in sein
> vorhandenes System implentieren.

Da sind wir wohl der gleichen Meinung - sonst würde ich mir nicht die 
Mühe machen, .sql-Versionen zu erstellen.

Schönen Gruß
Martin