DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten

[Sascha Mantscheff]

Da ich gerade erst anfange, mich mit dieser DB zu beschäftigen, stosse
ich auf einige Unklarheiten. Ich bitte, dumme Fragen zu entschuldigen,
aber trotzdem zu beantworten.

An DB-Versionen liegen mir vor eine Fassung von sourceforge
(opengeodb-0.2.5a-UTF8-sql, "SF") und eine Fassung des ADFC (D.sql, "ADFC").

"ADFC" scheint vollständiger und umfangreicher. Hier fehlen jedoch die
Inhalte der Tabellen hierarchies und type_names.
"SF" enthält type_names mit Inhalten und die Tabellenstruktur für
hierarchies, jedoch keine Werte dafür. type_names ist unvollständig
(d.h. es fehlen Werte, die in im Feld loc_type vorkommen).

In der Dokumentation auf sourceforge (Stand 2005) wird behauptet,
type_names sei einstweilen unwichtig. Nach den mir vorliegenden Daten
scheint das Gegenteil der Fall. Oder gibt es auch einen öffentlich
zugänglichen Datenbestand, in dem die Tabelle hierarchies gefüllt ist
und der weiter gepflegt wird?

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

[Martin Trautmann]

Sascha Mantscheff wrote:
> Da ich gerade erst anfange, mich mit dieser DB zu beschäftigen, stosse
> ich auf einige Unklarheiten. Ich bitte, dumme Fragen zu entschuldigen,
> aber trotzdem zu beantworten.
>
> An DB-Versionen liegen mir vor eine Fassung von sourceforge
> (opengeodb-0.2.5a-UTF8-sql, "SF") und eine Fassung des ADFC (D.sql, "ADFC").
>
> "ADFC" scheint vollständiger und umfangreicher. Hier fehlen jedoch die
> Inhalte der Tabellen hierarchies und type_names.

hierarchies sind derzeit nicht mehr enthalten, weil IMHO nicht
erforderlich und aufwändig zu pflegen.

Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese
automatisch abgeleitet werden könnten.

Daher habe ich für den Dump auch mal eingerichtet, dass die hiearchies
neu erstellt werden und habe
http://fa-technik.adfc.de/code/opengeodb/Dhier.sql usw.
erzeugt. Bisher habe ich aber keine Rückmeldung, ob das irgendwie
brauchbar ist.

> "SF" enthält type_names mit Inhalten und die Tabellenstruktur für
> hierarchies, jedoch keine Werte dafür. type_names ist unvollständig
> (d.h. es fehlen Werte, die in im Feld loc_type vorkommen).

Mit genauen Angaben lässt sich korrigieren, was so unklar im Raum steht.

> In der Dokumentation auf sourceforge (Stand 2005) wird behauptet,
> type_names sei einstweilen unwichtig.

 > Oder gibt es auch einen öffentlich
> zugänglichen Datenbestand, in dem die Tabelle hierarchies gefüllt ist
> und der weiter gepflegt wird?

s.o. - die hierarchies sind aber nur abgeleitete, redundante Daten, die
automatisch erstellt werden sollten.

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

[Sascha Mantscheff]

Besten Dank.

Martin Trautmann schrieb:

> Sascha Mantscheff wrote:
>  
>> Da ich gerade erst anfange, mich mit dieser DB zu beschäftigen, stosse
>> ich auf einige Unklarheiten. Ich bitte, dumme Fragen zu entschuldigen,
>> aber trotzdem zu beantworten.
>>
>> An DB-Versionen liegen mir vor eine Fassung von sourceforge
>> (opengeodb-0.2.5a-UTF8-sql, "SF") und eine Fassung des ADFC (D.sql, "ADFC").
>>
>> "ADFC" scheint vollständiger und umfangreicher. Hier fehlen jedoch die
>> Inhalte der Tabellen hierarchies und type_names.
>>    
>
> hierarchies sind derzeit nicht mehr enthalten, weil IMHO nicht
> erforderlich und aufwändig zu pflegen.
>
> Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese
> automatisch abgeleitet werden könnten.
>  

Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von
Dir genannte Hiearchietabelle erzeugt wurde.

> Daher habe ich für den Dump auch mal eingerichtet, dass die hiearchies
> neu erstellt werden und habe
> http://fa-technik.adfc.de/code/opengeodb/Dhier.sql usw.
> erzeugt. Bisher habe ich aber keine Rückmeldung, ob das irgendwie
> brauchbar ist.
>  
Was heisst usw.? Gibt es da noch mehr? - Im übrigen ist natürlich
richtig, dass der Grunddatenbestand keine abgeleiteten Daten enthalten
sollte.
>> "SF" enthält type_names mit Inhalten und die Tabellenstruktur für
>> hierarchies, jedoch keine Werte dafür. type_names ist unvollständig
>> (d.h. es fehlen Werte, die in im Feld loc_type vorkommen).
>>    
>
> Mit genauen Angaben lässt sich korrigieren, was so unklar im Raum steht.
>  
Es fehlen die type_names:
+-----------+
| loc_type  |
+-----------+
| 100900000 |
| 610000000 |
| 500100000 |
+-----------+

Gefunden mit:
select distinct (loc_type) from geodb_locations l left join
geodb_type_names t on l.loc_type=t.type_id where t.type_id is null
union
select distinct (coord_type) from geodb_coordinates c left join
geodb_type_names t on c.coord_type=t.type_id where t.type_id is null
union
select distinct (float_type) from geodb_floatdata f left join
geodb_type_names t on f.float_type=t.type_id where t.type_id is null
union
select distinct (int_type) from geodb_intdata f left join
geodb_type_names t on f.int_type=t.type_id where t.type_id is null
union
select distinct (text_type) from geodb_textdata f left join
geodb_type_names t on f.text_type=t.type_id where t.type_id is null

>> > 3) In der sourceforge-Fassung werden die Tabellen zwar vom Typ InnoDB
>> > deklariert, es werden jedoch keine foreign keys deklariert, die solche
>> > Fehler wie fehlende Typnamen vermeiden helfen würden. Was ist die
>> > Überlegung dahinter?
>>    
>
> Das sollten SQL-Experten beantworten, ich selbst brauche das nicht.
>  
Es würde zwar bei Inserts und Updates die Performance beeinträchtigen,
aber die Datenintegrität erhöhen. Wo immer es möglich ist, empfehle ich,
Relationen zwischen Tabellen mit Foreign-Key-Constraints abzusichern.

>  
>> > Im übrigen werde ich meine DB, wenn die genannten Mängel korrigiert
>> > sind, gerne zur Verfügung stellen. Gibt es dafür ein Procedere?
>>    
>
> Wenn du Daten bereitstellen kannst, solltest du sie z.B. auf fa-technik
> wieder einspielen.
>
> Wenn du Änderungen an der Datenstruktur hast, solltest du sie hier
> diskutieren.
>  

Neben der oben empfohlenen Einführung von Foreign Keys schlage ich vor,
alle Feldbezeichnungen so zu vereinheitlichen, dass Referenzen auf
identische Felder identische Namen haben. Zur Zeit gibt es (siehe
Union-Abfrage oben) diverse Felder namens ..._type, die alle dasselbe
meinen, nämlich eine Referenz auf die Tabelle type_names.

Im übrigen verstehe ich zwar einerseits die Anlage der Wertetabellen für
atomare Typen wie float, int, text und die Flexibilität, die damit
erzielt wird. Andererseits kommt mir die Struktur, die offenbar bis etwa
2005 gepflegt wurde, wesentlich einleuchtender vor. Die künstliche
Trennung von Primärschlüssel (loc_id) und Attributen und deren
Aufspaltung in typorientierte Tabellen kommt mir unter den Aspekten der
Datenpflege und der Programmierung eher kontraproduktiv vor. Was war
denn ausschlaggebend für diese Umstrukturierung?

Gruss
s.m.

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

[Martin Trautmann]

On 2008-01-10 09:52, Sascha Mantscheff wrote:
>> Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese
>> automatisch abgeleitet werden könnten.
>>
> Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von
> Dir genannte Hiearchietabelle erzeugt wurde.

Bist du sicher, dass die dir helfen würden?

sub create_hierarchies {
my ($country) = @_;
my $dpath = "opengeodb";
my $dfile = $dpath."/".$country.".tab";
my $hfile = $dpath."/".$country."hier.sql";
my $i=0;
my $hid;
my $hlevel;
my $hof;
my $mylevel=1;
my $hier0="0\t104"."\t0" x 8;
my %hier;
my ($key,$value);

while ($mylevel < 9) {
    print "pass: ".($mylevel+1);
    open (KEYD, "<:encoding(latin1)", $dfile) or die "can not open $dfile\n";
    while(<KEYD>){
        ($hid,$hlevel,$hof)=/^(\d+)\t(?:[^\t]*\t){12} *(\d+)\t*(\d+)(?:\t.*$)?/;
        if($mylevel  == $hlevel-1) {
            print "$i.$mylevel:$hid:$hlevel/$hof;\n" if $check;
            $hier{$hid} = $hier{$hof}?$hier{$hof}:$hier0;
            $hier{$hid} =~ s/^\d+((\t\d+){$mylevel})\t0/$hlevel$1\t$hid/;
            print "->$hier{$hid}\n" if $check;
            $i++;
        }
    }
    close (KEYD);
    $mylevel++;
}

open (KEYH, ">:encoding(utf8)", $hfile) or die "can not open $hfile\n";
while (($key,$value)= each %hier) {
    $value =~ s/\t0/\tnull/g;
    $value =~ s/\t/,/g;
    print KEYH "INSERT INTO geodb_hierarchies ($key,$value,null,null,null,3000-01-01); /* $country */\n";
}
}

>> Daher habe ich für den Dump auch mal eingerichtet, dass die hiearchies
>> neu erstellt werden und habe
>> http://fa-technik.adfc.de/code/opengeodb/Dhier.sql usw.
>> erzeugt. Bisher habe ich aber keine Rückmeldung, ob das irgendwie
>> brauchbar ist.
>>
> Was heisst usw.? Gibt es da noch mehr?

Schau einfach mal in das Verzeichnis. Die Hierarchie-Tabellen wurden
laenderweise erzeugt. Daher gibt es auch AThier.sql, Bhier.sql usw.

>>> "SF" enthält type_names mit Inhalten und die Tabellenstruktur für
>>> hierarchies, jedoch keine Werte dafür. type_names ist unvollständig
>>> (d.h. es fehlen Werte, die in im Feld loc_type vorkommen).
>>>
>>
>> Mit genauen Angaben lässt sich korrigieren, was so unklar im Raum steht.
>>
> Es fehlen die type_names:
> +-----------+
> | loc_type  |
> +-----------+
> | 100900000 |
> | 610000000 |
> | 500100000 |
> +-----------+

seltsam - der dump wird typischerweise erzeugt aus der Verkettung von
opengeodb-begin.sql, den Landes-SQL, extra.sql und opengeodb-end.sql

In http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql steht

INSERT INTO geodb_type_names VALUES(100900000,'de','Ortsteil');
INSERT INTO geodb_type_names VALUES(500100000,'de','Name');
INSERT INTO geodb_type_names VALUES(610000000,'de','Fläche');

Oder wie muesste der Befehl heissen, den du vermisst?

>>> > 3) In der sourceforge-Fassung werden die Tabellen zwar vom Typ InnoDB
>>> > deklariert, es werden jedoch keine foreign keys deklariert, die solche
>>> > Fehler wie fehlende Typnamen vermeiden helfen würden. Was ist die
>>> > Überlegung dahinter?
>>>
>>
>> Das sollten SQL-Experten beantworten, ich selbst brauche das nicht.
>>
> Es würde zwar bei Inserts und Updates die Performance beeinträchtigen,
> aber die Datenintegrität erhöhen. Wo immer es möglich ist, empfehle ich,
> Relationen zwischen Tabellen mit Foreign-Key-Constraints abzusichern.

Wenn du mir beschreiben kannst, wie das Endergebnis  fuer die sql-Datei
aussehen muss, dann kann ich das vielleicht hinzufuegen.
> Neben der oben empfohlenen Einführung von Foreign Keys schlage ich vor,
> alle Feldbezeichnungen so zu vereinheitlichen, dass Referenzen auf
> identische Felder identische Namen haben. Zur Zeit gibt es (siehe
> Union-Abfrage oben) diverse Felder namens ..._type, die alle dasselbe
> meinen, nämlich eine Referenz auf die Tabelle type_names.

ok, ich warte dann auf einen Vorschlag von dir, der moeglichst endgueltig
sein muesste. Da wir damit erneut die Datenstruktur aendern wuerden,
wuerde das in eine 0.2.7 einfliessen.

> Im übrigen verstehe ich zwar einerseits die Anlage der Wertetabellen für
> atomare Typen wie float, int, text und die Flexibilität, die damit
> erzielt wird. Andererseits kommt mir die Struktur, die offenbar bis etwa
> 2005 gepflegt wurde, wesentlich einleuchtender vor. Die künstliche
> Trennung von Primärschlüssel (loc_id) und Attributen und deren
> Aufspaltung in typorientierte Tabellen kommt mir unter den Aspekten der
> Datenpflege und der Programmierung eher kontraproduktiv vor. Was war
> denn ausschlaggebend für diese Umstrukturierung?

Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen
2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei?

Schoenen Gruss
Martin Trautmann

[Michael Diederich-2]

Hallo,

On Jan 10, 2008 9:52 AM, Sascha Mantscheff <922492@...> wrote:

> > Das sollten SQL-Experten beantworten, ich selbst brauche das nicht.
> Es würde zwar bei Inserts und Updates die Performance beeinträchtigen,
> aber die Datenintegrität erhöhen. Wo immer es möglich ist, empfehle ich,
> Relationen zwischen Tabellen mit Foreign-Key-Constraints abzusichern.

Ich wollte das schon einmal anfangen, kam leider noch nicht dazu..
Wenn du mir sagst, wie weit du bist und wobei du Hilfe gebrauchen
kannst..

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

[Sascha Mantscheff]

In den nächsten Tagen werde ich erst mal mit der DB arbeiten und ein
MySQL-Skript erstellen, das die von mir gewünschten Änderungen einbaut.
Wenn das funktioniert, werde ich es hier zur Verfügung stellen. Es wird
aber nur funktionieren in Datenbanken, die Foreign Key Constraints
unterstützen, und testen werde ich es mit MySQL 5/InnoDB.

s.m.

Michael Diederich schrieb:

> Hallo,
>
> On Jan 10, 2008 9:52 AM, Sascha Mantscheff <922492@...> wrote:
>
>  
>>> Das sollten SQL-Experten beantworten, ich selbst brauche das nicht.
>>>      
>> Es würde zwar bei Inserts und Updates die Performance beeinträchtigen,
>> aber die Datenintegrität erhöhen. Wo immer es möglich ist, empfehle ich,
>> Relationen zwischen Tabellen mit Foreign-Key-Constraints abzusichern.
>>    
>
> Ich wollte das schon einmal anfangen, kam leider noch nicht dazu..
> Wenn du mir sagst, wie weit du bist und wobei du Hilfe gebrauchen
> kannst..
>
> Michael
>  

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

[Sascha Mantscheff]

Martin Trautmann schrieb:

> On 2008-01-10 09:52, Sascha Mantscheff wrote:
>  
>>> Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese
>>> automatisch abgeleitet werden könnten.
>>>
>>>      
>> Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von
>> Dir genannte Hiearchietabelle erzeugt wurde.
>>    
>
> Bist du sicher, dass die dir helfen würden?
>  

Deine Skepsis ist berechtigt. Wenn ich es richtig verstehe, werden hier
*.tab-Dateien nach SQL gewandelt. Dann muss ich fragen, woher denn die
*.tab-Dateien kommen? Werden die aus dem Datenbestand abgeleitet, oder
sind es Grunddaten, die gepflegt werden?
> seltsam - der dump wird typischerweise erzeugt aus der Verkettung von
> opengeodb-begin.sql, den Landes-SQL, extra.sql und opengeodb-end.sql
>
> In http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql steht
>
> INSERT INTO geodb_type_names VALUES(100900000,'de','Ortsteil');
> INSERT INTO geodb_type_names VALUES(500100000,'de','Name');
> INSERT INTO geodb_type_names VALUES(610000000,'de','Fläche');
>  
Das sind schon die richtigen Befehle, und damit wird es auch stimmig.
Aber im Dump D.sql sind offenbar opengeodb-(begin|end).sql nicht enthalten.


> Wenn du mir beschreiben kannst, wie das Endergebnis  fuer die sql-Datei
> aussehen muss, dann kann ich das vielleicht hinzufuegen.
>  
Ich gebe mich die nächsten Tage mal dran.

> Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen
> 2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei?
>  

Wenn ich das so genau wüsste. Quelldaten liegen keine vor, nur
MySQL-Tabellen, die wohl aus früheren einem GeoDB-Import und
Nachbearbeitung entstanden sind. Die locations-Tabelle beispielsweise
sieht aus wie unten gezeigt.

Gruss
s.m.

+----------+--------------+------+-----+---------+----------------+
| Field    | Type         | Null | Key | Default | Extra          |
+----------+--------------+------+-----+---------+----------------+
| id       | int(12)      | NO   | PRI | NULL    | auto_increment |
| typ      | int(12)      | YES  |     | NULL    |                |
| name     | varchar(250) | YES  |     | NULL    |                |
| name_int | varchar(250) | YES  |     | NULL    |                |
| gs       | varchar(8)   | YES  |     | NULL    |                |
| adm0     | char(2)      | YES  | MUL | NULL    |                |
| adm1     | char(2)      | YES  | MUL | NULL    |                |
| adm2     | varchar(250) | YES  | MUL | NULL    |                |
| adm3     | varchar(250) | YES  | MUL | NULL    |                |
| adm4     | varchar(250) | YES  |     | NULL    |                |
| ort      | varchar(250) | YES  | MUL | NULL    |                |
| ortsteil | varchar(250) | YES  |     | NULL    |                |
| gemteil  | varchar(250) | YES  |     | NULL    |                |
| breite   | float        | YES  |     | NULL    |                |
| laenge   | float        | YES  |     | NULL    |                |
| kfz      | char(3)      | YES  |     | NULL    |                |
| plz      | text         | YES  |     | NULL    |                |
+----------+--------------+------+-----+---------+----------------+



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

[Peter Wendorff]

Ich habe grade mal versucht, herauszufinden, ob es eine Regelung gibt,
wie DBMS ohne Fremdschlüssel-Umsetzung mit den Angaben im SQL-Script
umgehen sollen, die Fremdschlüsselbeziehungen definieren.
Leider habe ich nichts generelles dazu gefunden.
Die MYSQL-Website besagt aber, dass in mysql, wo bisher nur
InnoDB-Tabellen Fremdschlüssel anwenden, in anderen Tabellenformaten die
Fremdschlüsselbeziehung einfach ignoriert (bzw. gelesen und in die
Tabellen-Metainformation für Exportzwecke gespeichert, aber die
Integrität nicht geprüft) wird.
Insofern sollte das Script hoffentlich auch in anderen DBMS
funktionieren - nur eben ohne der Integritätsprüfung.

Gruß
Peter Wendorff


Sascha Mantscheff schrieb:
> In den nächsten Tagen werde ich erst mal mit der DB arbeiten und ein
> MySQL-Skript erstellen, das die von mir gewünschten Änderungen einbaut.
> Wenn das funktioniert, werde ich es hier zur Verfügung stellen. Es wird
> aber nur funktionieren in Datenbanken, die Foreign Key Constraints
> unterstützen, und testen werde ich es mit MySQL 5/InnoDB.
>
> s.m
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Michael Diederich-2]

Hallo,

On Jan 10, 2008 12:23 PM, Peter Wendorff <wendorff@...> wrote:

> Ich habe grade mal versucht, herauszufinden, ob es eine Regelung gibt,
> wie DBMS ohne Fremdschlüssel-Umsetzung mit den Angaben im SQL-Script
> umgehen sollen, die Fremdschlüsselbeziehungen definieren.
> Leider habe ich nichts generelles dazu gefunden.
> Die MYSQL-Website besagt aber, dass in mysql, wo bisher nur
> InnoDB-Tabellen Fremdschlüssel anwenden, in anderen Tabellenformaten die
> Fremdschlüsselbeziehung einfach ignoriert (bzw. gelesen und in die
> Tabellen-Metainformation für Exportzwecke gespeichert, aber die
> Integrität nicht geprüft) wird.
> Insofern sollte das Script hoffentlich auch in anderen DBMS
> funktionieren - nur eben ohne der Integritätsprüfung.

Das ist korrekt. Wenn du myisam verwendest, werden Fremdschlüssel
einfach ignoriert. Wenn du die engine auf innodb änderst, werden die
Foreign Keys wieder automatisch geprüft (sofern nicht explizit
deaktiviert). Ein Nachteil entsteht also für <=mysql4-Benutzer nicht.

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

[Martin Trautmann]

In-Reply-To: <4785FE8F.4090606@...>

On 2008-01-10 12:16, Sascha Mantscheff wrote:
> Martin Trautmann schrieb:
>> On 2008-01-10 09:52, Sascha Mantscheff wrote:
>>> Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von
>>> Dir genannte Hiearchietabelle erzeugt wurde.
>>
>> Bist du sicher, dass die dir helfen würden?
>>
> Deine Skepsis ist berechtigt. Wenn ich es richtig verstehe, werden hier
> *.tab-Dateien nach SQL gewandelt.

Genau

> Dann muss ich fragen, woher denn die
> *.tab-Dateien kommen? Werden die aus dem Datenbestand abgeleitet, oder
> sind es Grunddaten, die gepflegt werden?

Die .tab-Daten entstammen der 0.2.4d-SQL-Version, die seither massiv als
Grunddaten erweitert wurden

Auf der Plattform, wo das laeuft, steht keine SQL-Umgebung zur Verfuegung.
Es laeuft dort alles ueber Text-Dateien und Perl-Scripts.

Die Basisdaten liegen daher in den .tab-Dateien vor, aus denen
.sql-Dateien konvertiert werden.

> Das sind schon die richtigen Befehle, und damit wird es auch stimmig.
> Aber im Dump D.sql sind offenbar opengeodb-(begin|end).sql nicht enthalten.

Deswegen wollte ich von dir wissen, von welcher Version du sprichst.
dump/D.sql ist nur ein vorlaeufiger Zwischenstand, um die Einbindung von
Ortsteilen und Strassen vorzufuehren. Ich hoffe, jemand koenne oder wolle
sich die Daten mal ansehen, ob diese ueberhaupt brauchbar sind.

>> Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen
>> 2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei?
>>
>
> Wenn ich das so genau wüsste. Quelldaten liegen keine vor, nur
> MySQL-Tabellen, die wohl aus früheren einem GeoDB-Import und
> Nachbearbeitung entstanden sind.

Ok, so alte Daten habe ich vielleicht noch irgendwo auf Backups. Zu der
Zeit damals interessierten mich nur die .txt-Versionen.

> Die locations-Tabelle beispielsweise
> sieht aus wie unten gezeigt.

> +----------+--------------+------+-----+---------+----------------+
> | Field    | Type         | Null | Key | Default | Extra          |
> +----------+--------------+------+-----+---------+----------------+
> | id       | int(12)      | NO   | PRI | NULL    | auto_increment |
> | typ      | int(12)      | YES  |     | NULL    |                |
> | name     | varchar(250) | YES  |     | NULL    |                |
> | name_int | varchar(250) | YES  |     | NULL    |                |
> | gs       | varchar(8)   | YES  |     | NULL    |                |
> | adm0     | char(2)      | YES  | MUL | NULL    |                |
> | adm1     | char(2)      | YES  | MUL | NULL    |                |
> | adm2     | varchar(250) | YES  | MUL | NULL    |                |
> | adm3     | varchar(250) | YES  | MUL | NULL    |                |
> | adm4     | varchar(250) | YES  |     | NULL    |                |
> | ort      | varchar(250) | YES  | MUL | NULL    |                |
> | ortsteil | varchar(250) | YES  |     | NULL    |                |
> | gemteil  | varchar(250) | YES  |     | NULL    |                |
> | breite   | float        | YES  |     | NULL    |                |
> | laenge   | float        | YES  |     | NULL    |                |
> | kfz      | char(3)      | YES  |     | NULL    |                |
> | plz      | text         | YES  |     | NULL    |                |
> +----------+--------------+------+-----+---------+----------------+

Ja, das sieht nach fruehesten Versionen von Thomas aus. Seither kam viel
overhead dazu, der mir im Normalfall als ueberfluessig erscheint. Der
Inhalt dieser Tabelle entspricht recht genau der
http://downloads.sourceforge.net/opengeodb/opengeodb-0.2.4d-UTF8-text-orte.zip

# Bedeutung der einzelnen Felder:
#
# Feld 1: eindeutiger Schlüssel (Primary Key)
# Felder 2 bis 8: hierarchische Verwaltungsgliederung, hier:
#      Feld  2: Staat (DE == Deutschland)
#      Feld  3: Bundesland, s.o.
#      Feld  4: Regierungsbezirk
#      Feld  5: Landkreis
#      Feld  6: Verwaltungszusammenschluss
#      Feld  7: Ort
#      Feld  8: Ortsteil/Stadtteil
#      Feld  9: Gemeindeteil unspezifizierter Art
#      Feld 10: Anderer Ort
# Felder 11 und 12: Koordinaten:
#      Feld 11: Längengrad
#      Feld 12: Breitengrad
# Felder 13 und 14: Andere Merkmale, hier:
#      Feld 13: Autokennzeichen
#      Feld 14: Postleitzahl(en)

Schoenen Gruss
Martin

--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Die Frage, die ich mir stelle ist aber: Wie sieht das generell aus mit
anderen DBMS-Systemen?
Wir haben schließlich nicht nur mysql-Nutzer - sondern abgesehen von
Text-Dateien auch diverse andere SQL-Systeme (postgre sql bin ich mir
ziemlich sicher, ms xml vermute ich....)
Deshalb stellt sich hier eher die Frage: Gibt es einen Standard, wie mit
so etwas umgegangen wird?

Gruß
Peter
>
> Das ist korrekt. Wenn du myisam verwendest, werden Fremdschlüssel
> einfach ignoriert. Wenn du die engine auf innodb änderst, werden die
> Foreign Keys wieder automatisch geprüft (sofern nicht explizit
> deaktiviert). Ein Nachteil entsteht also für <=mysql4-Benutzer nicht.
>
> Michael
>  

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

[Sascha Mantscheff]

Foreign Key Constraints gehören zum SQL92-Standard. Jede zu diesem
Standard kompatible DB kann die Statements zumindest parsen. Wenn die
Constraints nicht von der DB erzwungen werden, ist das nur ein Problem
für die Anwendungsprogrammierung, aber nicht für die Datenhaltung.
"ms xml" soll MS-SQL heissen, nehme ich an? Ist angeblich auch kompatibel.

s.m.

Peter Wendorff schrieb:

> Die Frage, die ich mir stelle ist aber: Wie sieht das generell aus mit
> anderen DBMS-Systemen?
> Wir haben schließlich nicht nur mysql-Nutzer - sondern abgesehen von
> Text-Dateien auch diverse andere SQL-Systeme (postgre sql bin ich mir
> ziemlich sicher, ms xml vermute ich....)
> Deshalb stellt sich hier eher die Frage: Gibt es einen Standard, wie mit
> so etwas umgegangen wird?
>
> Gruß
> Peter
>  
>> Das ist korrekt. Wenn du myisam verwendest, werden Fremdschlüssel
>> einfach ignoriert. Wenn du die engine auf innodb änderst, werden die
>> Foreign Keys wieder automatisch geprüft (sofern nicht explizit
>> deaktiviert). Ein Nachteil entsteht also für <=mysql4-Benutzer nicht.
>>
>> Michael
>>  
>>    
>
>  

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

[Sascha Mantscheff]

Je länger ich mich damit befasse, desto mehr glaube ich, dass diese
Datenbankstruktur Mängel aufweist.

Insbesondere stutzig werde ich bei den inhaltlich expliziten Check
Constraints. Aus der Tabelle textdata wird type_names von den Feldern
text_type, date_type_since und date_type_until referenziert. text_type
und date_type_since sind dabei durch Check-Constraints gesichert,
date_type_until ist es nicht. Das ist wahrscheinlich nur ein
Flüchtigkeitsfehler, zeigt aber, dass der beschrittene Weg unsicher ist.

Check Constraints stehen unter MySQL nicht zur Verfügung. Da MySQL eine
sehr verbreitete Plattform ist, könnte das ein Grund sein, zu versuchen,
ohne sie auszukommen. Wesentlicher erscheint mir jedoch, dass hier
willkürliche inhaltliche Einschränkungen (willkürlich wegen der
willkürlichen Wahl der Schlüssel) eingebaut werden, die besser eine
strukturelle Entsprechung in den Tabellen fänden.

Grund für die Unschönheit scheint mir, dass type_names de facto nicht
nur als Namenstabelle fungiert, sondern auch als Referenz für den
Wertevorrat von Typen. Da aber unterschiedliche Typen in dieser Tabelle
zusammengefasst sind, werden o.g. Check-Constraints erforderlich. Dass
das keine saubere Anlage ist, erkennt man daran, dass die
Check-Constraints, die sich explizit auf bestimmte Schlüsselwerte
beziehen, ohne Kenntnis der Inhalte der DB nicht verständlich wären.

Ich plädiere daher für eine Ergänzung der Struktur um die Tabellen
type_date, type_text, type_float, type_int, in denen die dem jeweiligen
atomaren Datentyp zugehörenden type_names referenziert werden, die nach
wie vor in einer gemeinsamen Tabelle bleiben. Die Referenz läuft dann
also beispielsweise von textdata.text_type über type_text.type_name in
die Tabelle type_names. Damit werden die auf konkrete Datenwerte
bezogenen Check-Constraints überflüssig und durch
Foreign-Key-Constraints ersetzt. Die Tabelle type_names enthält dann
tatsächlich nur noch Namen.

---

Wenn ich Dich (Martin) richtig verstehe, werden die Daten zur Zeit im
.tab-Format gepflegt. Wäre es dann nicht sinnvoll, statt der SQL-Dateien
die Skripte anzubieten, mit denen sie generiert werden? Mir geht es
dabei um 3 Dinge:
1. Einen "offiziellen" Ort, an dem die Daten gepflegt werden. Das
scheint ja bei Dir angesiedelt zu sein.
2. Ein Verfahren, mit dem Updates schnell eingepflegt werden können.
Diff und Patch sind dafür hervorragend geeignet und könnten auf den
.tab-Dateien aufsetzen.
3. Eine DB-Struktur, die leicht verständlich ist und mit der ohne Umwege
(= Nachschlagen in Werte-Tabellen) programmiert werden kann.

Wenn nun statt der SQL-Fassungen die .tab-Fassungen die verbindlichen
sind, ist es im Prinzip ja ohnehin jedem selbst überlassen, welche
DB-Struktur er daraus generiert. Andererseits will man das Rad ja nicht
immer neu erfinden. Mein Weg wäre, die .tab-Dateien 1:1 in entsprechende
SQL-Dateien zu überführen und daraus dann mit SQL-Skripten die mir
genehme DB-Struktur zu erzeugen.

Aber zuvörderst erwächst aus alledem die Frage, in welchem Format (.tab,
SQL oder was (vielleicht XML?)?) die DB künftig bearbeitet und in
welchem sie zur Verfügung gestellt wird (wobei ich mal davon ausgehe,
dass das ein- und dasselbe ist).

Gruss
s.m.

Martin Trautmann schrieb:

> In-Reply-To: <4785FE8F.4090606@...>
>
> On 2008-01-10 12:16, Sascha Mantscheff wrote:
>  
>> Martin Trautmann schrieb:
>>    
>>> On 2008-01-10 09:52, Sascha Mantscheff wrote:
>>>      
>>>> Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von
>>>> Dir genannte Hiearchietabelle erzeugt wurde.
>>>>        
>>> Bist du sicher, dass die dir helfen würden?
>>>
>>>      
>> Deine Skepsis ist berechtigt. Wenn ich es richtig verstehe, werden hier
>> *.tab-Dateien nach SQL gewandelt.
>>    
>
> Genau
>
>  
>> Dann muss ich fragen, woher denn die
>> *.tab-Dateien kommen? Werden die aus dem Datenbestand abgeleitet, oder
>> sind es Grunddaten, die gepflegt werden?
>>    
>
> Die .tab-Daten entstammen der 0.2.4d-SQL-Version, die seither massiv als
> Grunddaten erweitert wurden
>
> Auf der Plattform, wo das laeuft, steht keine SQL-Umgebung zur Verfuegung.
> Es laeuft dort alles ueber Text-Dateien und Perl-Scripts.
>
> Die Basisdaten liegen daher in den .tab-Dateien vor, aus denen
> .sql-Dateien konvertiert werden.
>
>  
>> Das sind schon die richtigen Befehle, und damit wird es auch stimmig.
>> Aber im Dump D.sql sind offenbar opengeodb-(begin|end).sql nicht enthalten.
>>    
>
> Deswegen wollte ich von dir wissen, von welcher Version du sprichst.
> dump/D.sql ist nur ein vorlaeufiger Zwischenstand, um die Einbindung von
> Ortsteilen und Strassen vorzufuehren. Ich hoffe, jemand koenne oder wolle
> sich die Daten mal ansehen, ob diese ueberhaupt brauchbar sind.
>
>  
>>> Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen
>>> 2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei?
>>>
>>>      
>> Wenn ich das so genau wüsste. Quelldaten liegen keine vor, nur
>> MySQL-Tabellen, die wohl aus früheren einem GeoDB-Import und
>> Nachbearbeitung entstanden sind.
>>    
>
> Ok, so alte Daten habe ich vielleicht noch irgendwo auf Backups. Zu der
> Zeit damals interessierten mich nur die .txt-Versionen.
>
>  
>> Die locations-Tabelle beispielsweise
>> sieht aus wie unten gezeigt.
>>    
>
>  
>> +----------+--------------+------+-----+---------+----------------+
>> | Field    | Type         | Null | Key | Default | Extra          |
>> +----------+--------------+------+-----+---------+----------------+
>> | id       | int(12)      | NO   | PRI | NULL    | auto_increment |
>> | typ      | int(12)      | YES  |     | NULL    |                |
>> | name     | varchar(250) | YES  |     | NULL    |                |
>> | name_int | varchar(250) | YES  |     | NULL    |                |
>> | gs       | varchar(8)   | YES  |     | NULL    |                |
>> | adm0     | char(2)      | YES  | MUL | NULL    |                |
>> | adm1     | char(2)      | YES  | MUL | NULL    |                |
>> | adm2     | varchar(250) | YES  | MUL | NULL    |                |
>> | adm3     | varchar(250) | YES  | MUL | NULL    |                |
>> | adm4     | varchar(250) | YES  |     | NULL    |                |
>> | ort      | varchar(250) | YES  | MUL | NULL    |                |
>> | ortsteil | varchar(250) | YES  |     | NULL    |                |
>> | gemteil  | varchar(250) | YES  |     | NULL    |                |
>> | breite   | float        | YES  |     | NULL    |                |
>> | laenge   | float        | YES  |     | NULL    |                |
>> | kfz      | char(3)      | YES  |     | NULL    |                |
>> | plz      | text         | YES  |     | NULL    |                |
>> +----------+--------------+------+-----+---------+----------------+
>>    
>
> Ja, das sieht nach fruehesten Versionen von Thomas aus. Seither kam viel
> overhead dazu, der mir im Normalfall als ueberfluessig erscheint. Der
> Inhalt dieser Tabelle entspricht recht genau der
> http://downloads.sourceforge.net/opengeodb/opengeodb-0.2.4d-UTF8-text-orte.zip
>
> # Bedeutung der einzelnen Felder:
> #
> # Feld 1: eindeutiger Schlüssel (Primary Key)
> # Felder 2 bis 8: hierarchische Verwaltungsgliederung, hier:
> #      Feld  2: Staat (DE == Deutschland)
> #      Feld  3: Bundesland, s.o.
> #      Feld  4: Regierungsbezirk
> #      Feld  5: Landkreis
> #      Feld  6: Verwaltungszusammenschluss
> #      Feld  7: Ort
> #      Feld  8: Ortsteil/Stadtteil
> #      Feld  9: Gemeindeteil unspezifizierter Art
> #      Feld 10: Anderer Ort
> # Felder 11 und 12: Koordinaten:
> #      Feld 11: Längengrad
> #      Feld 12: Breitengrad
> # Felder 13 und 14: Andere Merkmale, hier:
> #      Feld 13: Autokennzeichen
> #      Feld 14: Postleitzahl(en)
>
> Schoenen Gruss
> Martin
>
>  

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

[Martin Trautmann]

In-Reply-To: <47861883.10903@...>

On 2008-01-10 14:07, Sascha Mantscheff wrote:
> Je länger ich mich damit befasse, desto mehr glaube ich, dass diese
> Datenbankstruktur Mängel aufweist.
>
> Insbesondere stutzig werde ich bei den inhaltlich expliziten Check
> Constraints. Aus der Tabelle textdata wird type_names von den Feldern
> text_type, date_type_since und date_type_until referenziert.

Die checks wirken historisch gewachsen, aber nicht vollstaendig und teils
auch eher mit Warnungs-Charakter als mit grundsaetzlich erfuellbaren
Bedingungen.

> Wesentlicher erscheint mir jedoch, dass hier
> willkürliche inhaltliche Einschränkungen (willkürlich wegen der
> willkürlichen Wahl der Schlüssel) eingebaut werden, die besser eine
> strukturelle Entsprechung in den Tabellen fänden.

Das ist mir zu schwammig

> Grund für die Unschönheit scheint mir, dass type_names de facto nicht
> nur als Namenstabelle fungiert, sondern auch als Referenz für den
> Wertevorrat von Typen.

Ist das so? Wodurch?

> Ich plädiere daher für eine Ergänzung der Struktur um die Tabellen
> type_date, type_text, type_float, type_int, in denen die dem jeweiligen
> atomaren Datentyp zugehörenden type_names referenziert werden, die nach
> wie vor in einer gemeinsamen Tabelle bleiben.

Ich bin da voellig leidenschaftslos und kann versuchen, jeden Vorschlag zu
uebernehmen. Ich bitte da aber um einen Konsens, der auf moeglichst
breiter Basis steht.

Es sollten keinesfalls mehr redundante Daten werden.

> Wenn ich Dich (Martin) richtig verstehe, werden die Daten zur Zeit im
> .tab-Format gepflegt. Wäre es dann nicht sinnvoll, statt der SQL-Dateien
> die Skripte anzubieten, mit denen sie generiert werden?

Wozu? Man kann die .tab-Daten jederzeit abrufen. Es soll aber auch einmal
die Moeglichkeit geben, ueber das Web-Interface einen frischen Dump zu
erstellen. Damit das nicht ausufert, werden das vielleicht nur diffs zu
einem release-dump.

> Mir geht es
> dabei um 3 Dinge:
> 1. Einen "offiziellen" Ort, an dem die Daten gepflegt werden. Das
> scheint ja bei Dir angesiedelt zu sein.

solange niemand etwas besseres hat, ja

> 2. Ein Verfahren, mit dem Updates schnell eingepflegt werden können.
> Diff und Patch sind dafür hervorragend geeignet und könnten auf den
> .tab-Dateien aufsetzen.

nein, diff und patch taugen dafuer weniger, weil die Eingriffe zu massiv
und direkt waeren. Es ist relativ einfach, alle Korrekturen in
entsprechende URLs umzuformulieren und z.B. ueber wget und das
Web-Interface durchzufuehren.

> 3. Eine DB-Struktur, die leicht verständlich ist und mit der ohne Umwege
> (= Nachschlagen in Werte-Tabellen) programmiert werden kann.

Kommt darauf an, wer was damit machen will. Die .tabs sind recht
effizient, enthalten aber nur einen Teil der Daten. Darueber hinausgehende
Daten (andere Schreibweisen, versionierte Daten, Zusatzdaten, ...) fehlen
in den .tab-Dateien und liegen in extra.sql - diese Daten sollen
demnaechst erheblich ausgebaut werden, wenn ich z.B. die laufenden
Aenderungen der Gemeindstrukturen aus den letzten Jahren einpflegen werde.

> Wenn nun statt der SQL-Fassungen die .tab-Fassungen die verbindlichen
> sind, ist es im Prinzip ja ohnehin jedem selbst überlassen, welche
> DB-Struktur er daraus generiert. Andererseits will man das Rad ja nicht
> immer neu erfinden. Mein Weg wäre, die .tab-Dateien 1:1 in entsprechende
> SQL-Dateien zu überführen und daraus dann mit SQL-Skripten die mir
> genehme DB-Struktur zu erzeugen.

Genau das passiert eigentlich jetzt schon. Du kannst das statt dort ueber
perl auch bei dir ueber SQL machen.

> Aber zuvörderst erwächst aus alledem die Frage, in welchem Format (.tab,
> SQL oder was (vielleicht XML?)?) die DB künftig bearbeitet und in
> welchem sie zur Verfügung gestellt wird (wobei ich mal davon ausgehe,
> dass das ein- und dasselbe ist).

<land>.tab ist die Einschraenkung auf reine Basisdaten.
Am haeufigsten benoetigt wird wohl nur die PLZ.tab, die bisher nicht
bearbeitet werden kann und die auch noch nicht in .sql umgewandelt wird.

Darueber hinaus gibt es bei manchen aber durchaus Bedarf an Daten, die
nicht in das .tab-Format passen. Eine der offenen Aenderungen am
.tab-Format ist z.B. die Aufnahme einer Sprachversion fuer den Namen
(.tab->.sql verwendet hier grundsaetzlich "de", was z.B. in der Schweiz
und in Belgien oft schlichtweg falsch ist).

Schoenen Gruss
Martin

--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Sascha Mantscheff schrieb:
> "ms xml" soll MS-SQL heissen, nehme ich an? Ist angeblich auch kompatibel.
>  
Ja - klar ;) sorry.
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)