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

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