ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002)

Hallo,

die Struktur der opengeodb sieht derzeit vielerlei Schreibvarianten vor, speziell:

INSERT INTO geodb_type_names VALUES(500100000,'de','Name');
INSERT INTO geodb_type_names VALUES(500100001,'de','ISO 3166 Alpha-2');
INSERT INTO geodb_type_names VALUES(500100002,'de','Sortiername');
INSERT INTO geodb_type_names VALUES(500100003,'de','ISO_3166_2');

http://surfnet.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt beschreibt dazu:

        NAME                  500100000
        ISO_3166_1_ALPHA_2    500100001
        NAME_7BITLC           500100002 // 7 Bit, Lower case
        ISO_3166_2            500100003

Ich vermute, meine derzeitige Implementierung ist hier falsch, denn ich verwende fuer 500100002 nicht lower case, sondern upper case.

Was ist euch lieber, was ist besser? Ich selbst finde upper-case gewohnter, kann aber gerne auf lower case umstellen.

Wofuer dient ein solcher Sortiername? Bei mir ist er vor allem auch ein Suchmerkmal, das schneller funktioniert, als ueber Gross-/Kleinschreibung, mit und ohne Umlaute.

Mein naechster Fehler ist aber, dass ich hier die Schreibweise noch recht unberuehrt lasse. Daher kann der gleiche Ort dennoch in unterschiedlichen Schreibvarianten zu Problem fuehren. Was ist richtig?
* ALT RUPPIN
* ALT-RUPPIN
* ALTRUPPIN

Bisher belasse ich es hier bei der Originalschreibweise. Mein Vorschlag: alle Trennzeichen fallen in Zukunft heraus: Leerzeichen und Bindestriche.

Was gehoert in den Sortiernamen aber hinein? Im Augenblick ist das ganz pragmatisch: Der Name (500100000) enthaelt eine uebliche Langversion des Namens (Beispiel: "Kehl am Rhein" oder "Kehl (Rhein)" zur Unterscheidung von "Kehl in Bayern"). Der Sortiername enthaelt nur die Kurzversion ("KEHL"), unterscheidet also in der Sortierung nicht ueber Namens-Zusaetze (was gerade bei der Sortierung nach mehr als einem Merkmal deutlich unterschiedliche Resultate ergibt).

Ist das fuer euch ok?

Die lange Schreibweise ist manchmal in der Gemeinde selbst nicht unbedingt gelaeufig: Bei Gemeindedaten entstammt diese Schreibvariante jenem Amt, das den amtlichen Gemeindeschluessel erstellt und dabei bei Bedarf durch Zusaetze verhindert, dass in diesem Verzeichnis gleichnamige Gemeinden aufgefuehrt werden.

Was ist mit dem SQL-dump? Ist es ueberhaupt sinnvoll, die Datenmenge zum Austausch, Archivierung, Versionierung mit diesen Daten aufzublaehen, statt hier einen passenden SQL-Befehl aufzunehmen, der ueberall dort durch eine moeglichst einfache Regel den Typ 500100002 aus 500100000 berechnet, wo dies moeglich ist? Im SQL-Dump wuerden dann nur jene Daten uebergeben, wo nicht automatisch der Wert von 500100002 sich aus lower(500100000) ergeben wuerde?

Und nach welchen aufwaendigeren Regeln sollte der Typ 500100002 bestimmt werden?

Beispiele:
* Amt Neuhaus -> "NEUHAUS" oder "AMTNEUHAUS"
* Verwaltungsgemeinschaft Neuhaus -> "NEUHAUS" oder "VERWALTUNGSGEMEINSCHAFTNEUHAUS"
* VG Neuhaus -> "NEUHAUS" oder "VGNEUHAUS"

... ich verwende hier bisher "NEUHAUS"

* St. Peter-Ording -> "STPETER", "SANKTPETER", "SANKTPETERORDING", "STPETERORDING", ...
* Schloss-Str. -> "SCHLOSSSTRASSE", "SCHLOSSTRASSE", "SCHLOSSSTR", "SCHLOSSSTR.", ...

Was ist hier am sinnvollsten?

Schoenen Gruss
Martin