[opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten

[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


-- 
View this message in context: http://www.nabble.com/DB-Versionen%2C-geodb_hierarchies%2C-geodb_type_names-und-Ungereimtheiten-tp14718223p14730649.html
Sent from the Php German - opengeodb mailing list archive at Nabble.com.