[opengeodb] Nochmal zu Prosa-Namen wie "Brandis bei Wurzen" (war: Inkonsistenzen der Download-Daten)

[Frank Glück]

Hallo Peter,

Peter Wenddorf schrieb:
>Frank Glück schrieb:
[...]
>> Demnach kann man ja auch davon ausgehen, dass der "Prosateil" wirklich
immer
>> an den offiziellen Namen anzuhängen ist und der umgekehrte Fall niemals
>> vorkommt(?) Was spricht dann dagegen, die beiden Datentypen einfach auch
>> getrennt voneinander vorzuhalten - dann soll sie doch derjenige für seine
>> speziellen Zwecke wieder zusammenführen, der sie wirklich in dieser Form
>> braucht.
>>   
>Zum Beispiel, dass durch den reinen Prosateil niemandem geholfen wäre.

Einspruch! Mir sehr wohl. Und ich denke, da bin ich auch nicht der Einzige.
Für meine Anwendung werde ich nämlich die Hauptinfo (hier also: "Brandis")
getrennt von der Metainfo ("bei Wurzen") ausgeben - die Hauptinfo in einer
Listendarstellung direkt auf einer HTML-Seite und die Metainfo in einem
Tooltipp, der erst beim Überfahren mit der Maus sichtbar werden soll. Denn
die Metainfo ist zwar durchaus hilfreich und keineswegs überflüssig, aber
das eigentliche Location-Textfeld ist in seiner Länge dadurch kaum mehr
berechenbar, weil es eben mal mit und mal ohne Metainfo daherkommen und
dadurch beinahe beliebig lang werden kann, was für eine geordnete,
platzsparende und zugleich ästhetische Listen-Darstellung am Bildschirm eben
durchaus Probleme aufwerfen kann, wenn neben den eigentlichen Location-Namen
auch noch andere Daten platziert werden sollen.

Es ist eben "nur" eine Metainfo, und für eine solche sollte man die Wahl
haben, ob und wenn ja, wie man sie benötigt. Das wird optimal nur durch ein
weiteres Datenfeld, das nur die Metainfo enthält, erreicht. Hingegen wäre
die Lösung mit einem NurHauptinfo-Feld und einem Hauptinfo+Metainfo-Feld
nicht nur schon wieder redundant, sondern sie würde auch wiederum darauf
hinauslaufen, dass man die eigentlichen Rohdaten eben nur durch
String-Vergleiche wiederherstellen kann. Dass "bei Wurzen" ohne "Brandis"
natürlich keinen Sinn macht, ist schließlich gerade das Wesensmerkmal einer
Metainfo.

>>> Wie du schon entdeckt hast, steht in 
>>> 500100002 genau das zur Verfügung, was du brauchst. Den Zusatzaufwand 
>>> der Konvertierung kannst du entweder im Moment der Abfrage machen oder 
>>> dir vorab eine Rückkonvertierung ausdenken, die über den ASCII-Teil dir 
>>> den relevanten Teil der Kurzform zurückgibt.
>>> Ebenso kannst du natürlich eine Wildcard-Suche verwenden, die dir alles 
>>> liefert, was mit Brandis beginnt.
>>>     
>> Nein, umgekehrt: man sollte nicht darauf angewiesen sein, sich über
Skripte
>> (womöglich noch über den redundanten Sortiernamen) mehr oder weniger
>> aufwändig das wiederherstellen zu müssen, was die Datenbank auch im
>> Rohformat liefern könnte. Stimme ich Dir zu.
>>  Ebenso, wie auch derjenige, der für seine
>> spezielle Anwendung Sortiernamen benötigt, sich diese doch nach seinen
>> eigenen Anforderungen, die ja weit auseinandergehen können, selbst
erstellen
>> könnte.
>Die Idee ist gut - aber wie an so vielen anderen Stellen auch:
>Das Problem taucht auf, sobald sich Nutzer selbst Gedanken darüber 
>machen müssen, wie sie das tun können - denn viel zu viele tun gerade 
>das eben nicht.
[...]
>1) die wenigsten Nutzer machen sich tatsächlich so weitreichende 
>Gedanken, die meisten werden sich beschweren, dass das, was 
>vorher ging, mit aktuellen Versionen einfach nicht mehr geht

Ja, das mag sein, deshalb kann ich die hier momentan noch bestehenden Zwänge
durchaus nachvollziehen und will da auch gar nicht weiter drauf herumreiten
- es wurde in der Vergangenheit auch schon oft genug angesprochen. Bin ja
selbst auch kein Verfechter der reinen Lehre, wenn ich momentan noch auf die
Bereitstellung der Hierarchien bestehe ...;-)

>2) SQL-Befehle muss man natürlich nicht zur Verfügung stellen, aber die 
>Dokumentation sollte da sein - und dann sollte das ganze in irgendeiner 
>Sprache soweit umgesetzt worden sein, dass die Dokumentation auch auf 
>Verwendbarkeit getestet ist. Wenn das nicht SQL ist, ist das egal - es 
>auch oder nur in SQL zur Verfügung zu stellen, kann aber nicht schaden.

Mal sehen, das wäre schon höheres SQL, als ich bislang beherrsche, aber
vielleicht lese ich mich da mal noch ein und bastele was ...

Grüße,
Frank