« Return to Thread: ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002)
Re: ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002)
by Simon Schmid
::
Rate this Message:
Hallo,
das Problem mit den Namen ist mehr bekannt. Meiner Meinung nach
sollten immer die offiziellen Namen verwendet werden wie sie z.B. in
den Gemeinde/Orts/Bezirkslisten von Statistik Austria drin stehen.
Sollte der aktuell in der Datenbank befindliche Namen anders lauten,
sollte man diesen erhalten und die Gültigkeit (valid_until) "beenden"
weil der Name nicht mehr offiziell so gültig ist. Gefunden würde der
Datensatz schlussendlich mit beiden Namen. Aber wenn man alle Orte o.ä
auflisten möchte, kann man hier nur die offiziell gültigen Namen
auflisten lassen. Durch diese offiziell gültigen Namen wird auch das
Problem mit St. oder Sankt gelöst.
Ansonsten muss man halt für die gängisten Kürzel einen Filter einbauen
und halt noch eine 2. Bedinung einfügen wie WHERE name = "STPOELTEN"
OR name = "SANKTPOELTEN"
Buchstaben wie ein dreifaches 'S' wegzulassen, würde ich nicht machen.
Da ich z.B. in einer Suchabfrage das deutsche SZ durch ein doppel S
ersetzen würde. Und nicht prüfen möchte ob der vorherige oder
nachfolgende Buchstabe auch ein 'S' ist. Auch Zahlen würde ich im
Sortiernamen speichern, da diese ja ebenfalls nötig sind um den
Datensatz zu finden. Es sollte hier kein Informationsverlust
stattfinden, sondern lediglich eine einheitliche "Formatierung" sprich
7bit ASCII und UPPER- oder lowercase und keine Leerzeichen.
Gruss
Simon
2008/1/23 Ingmar Lötzsch <iloetzsch@...>:
> Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste
> Weise von einem Computer berechenbar ist - am besten ausschließlich mit
> SQL - und möglichst wenig Ausnahmen macht.
>
> - keine Buchstaben weglassen, etwa sss-> SS
> - keine Buchstaben hinzufügen, etwa St. -> SANKT
>
> Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des
> offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden,
> etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St.
> ...". Dann wäre es wünschenswert, wenn man es bei St. -> ST belassen könnte.
>
> Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle
> Bezeichnung festlegen, andere nicht. Dann könnte man die Forderung
> aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte
> verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die
> Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird.
>
> --
> Mailingliste OpenGeoDB
> Listenadresse: opengeodb@...
> Informationen: http://opengeodb.de
> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
>--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
das Problem mit den Namen ist mehr bekannt. Meiner Meinung nach
sollten immer die offiziellen Namen verwendet werden wie sie z.B. in
den Gemeinde/Orts/Bezirkslisten von Statistik Austria drin stehen.
Sollte der aktuell in der Datenbank befindliche Namen anders lauten,
sollte man diesen erhalten und die Gültigkeit (valid_until) "beenden"
weil der Name nicht mehr offiziell so gültig ist. Gefunden würde der
Datensatz schlussendlich mit beiden Namen. Aber wenn man alle Orte o.ä
auflisten möchte, kann man hier nur die offiziell gültigen Namen
auflisten lassen. Durch diese offiziell gültigen Namen wird auch das
Problem mit St. oder Sankt gelöst.
Ansonsten muss man halt für die gängisten Kürzel einen Filter einbauen
und halt noch eine 2. Bedinung einfügen wie WHERE name = "STPOELTEN"
OR name = "SANKTPOELTEN"
Buchstaben wie ein dreifaches 'S' wegzulassen, würde ich nicht machen.
Da ich z.B. in einer Suchabfrage das deutsche SZ durch ein doppel S
ersetzen würde. Und nicht prüfen möchte ob der vorherige oder
nachfolgende Buchstabe auch ein 'S' ist. Auch Zahlen würde ich im
Sortiernamen speichern, da diese ja ebenfalls nötig sind um den
Datensatz zu finden. Es sollte hier kein Informationsverlust
stattfinden, sondern lediglich eine einheitliche "Formatierung" sprich
7bit ASCII und UPPER- oder lowercase und keine Leerzeichen.
Gruss
Simon
2008/1/23 Ingmar Lötzsch <iloetzsch@...>:
> Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste
> Weise von einem Computer berechenbar ist - am besten ausschließlich mit
> SQL - und möglichst wenig Ausnahmen macht.
>
> - keine Buchstaben weglassen, etwa sss-> SS
> - keine Buchstaben hinzufügen, etwa St. -> SANKT
>
> Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des
> offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden,
> etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St.
> ...". Dann wäre es wünschenswert, wenn man es bei St. -> ST belassen könnte.
>
> Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle
> Bezeichnung festlegen, andere nicht. Dann könnte man die Forderung
> aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte
> verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die
> Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird.
>
> --
> Mailingliste OpenGeoDB
> Listenadresse: opengeodb@...
> Informationen: http://opengeodb.de
> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
>
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
« Return to Thread: ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002)
| Free embeddable forum powered by Nabble | Forum Help |
