Zeichen bei SELECT ignorieren

[Furtbichler]

Zitat von DeddyH:

Das stimmt so nicht ganz, aber der Aufwand dürfte abschrecken (Punkt 2.3).

Nett. Aber ne SQL-UDF ist das tropsdem nich.

[p80286]

Ich hatte vor einiger Zeit ebenfalls das Vergnügen mich mit Telefonnummern herum zu schlagen.
Nach einer Woche Hampelei mit Berücksichtigung von deutschen,amerikanischen,englischen und Sekretärinenvorlieben (alles natürlich wohlbegründet und jede Änderung ein Verstoß gegen die Menschenrechte) hat ein netter Mensch mit der Faust auf den Tisch gehauen, und ein Standardformat definiert. Die Umstellung war nach 2 Stunden (mit Delphi) erledigt.
Jetzt läuft jede Woche eine Prüfabfrage die eine Fehlerliste generiert und gut ist.

Gruß
K-H

[fillibuster]

Hi,

erstmal danke für eure Antworten. Da teste ich mir das Passende raus. Hatte gestern festgestellt, dass die folgende Abfrage auch funktioniert:

Code:

SELECT * FROM contact WHERE phone LIKE '%3%0%1%2%3%4%5%6'

für z. B. [phone]. Ist ja bald Halloween *grusel*

Viele Grüße ...

[baumina]

Zitat von fillibuster:

Hi,

erstmal danke für eure Antworten. Da teste ich mir das Passende raus. Hatte gestern festgestellt, dass die folgende Abfrage auch funktioniert:

Code:

SELECT * FROM contact WHERE phone LIKE '%3%0%1%2%3%4%5%6'

für z. B. [phone]. Ist ja bald Halloween *grusel*

Viele Grüße ...

Das entspricht dann meiner Lösung, nur gebe ich hinter der 6 auch noch ein % mit.

[fillibuster]

Hi,

Zitat von baumina:

Das entspricht dann meiner Lösung, nur gebe ich hinter der 6 auch noch ein % mit.

Stimmt, hatte aber erst gar nicht gedacht, dass so ein SQL Konstrukt funktioniert

Danke euch

[Furtbichler]

Zitat von fillibuster:

Code:

SELECT * FROM contact WHERE phone LIKE '%3%0%1%2%3%4%5%6'

für z. B. [phone].

Und [phone] passt auch

[baumina]

Zitat von Furtbichler:

Zitat von fillibuster:

Code:

SELECT * FROM contact WHERE phone LIKE '%3%0%1%2%3%4%5%6'

für z. B. [phone].

Und [phone] passt auch

Aber die Ergebnismenge bleibt überschaubar und kann zur Not nochmal genauer betrachtet werden.

[Furtbichler]

Zitat von baumina:

Aber die Ergebnismenge bleibt überschaubar und kann zur Not nochmal genauer betrachtet werden.

Das muß nicht 'zur Not' genauer betrachtet werden, sondern in jedem Fall. Und wenn Du dich darauf verlässt...nun ja. Wenn die Stecknadel in einer Handvoll Heu steckt, ist sie immer noch schwer zu finden.

Ich stehe auf dem Standpunkt, das ein Problem, das ordentlich lösbar ist, auch ordentlich gelöst werden sollte.

PS: Als Lösung für die Eingabe kompletter Telefonnummern mag es als Notbehelf durchgehen, ich würde die paar Daten (da sie ja überschaubar sind) trotzdem in-Memory filtern, und dann richtig.

[baumina]

Ich habe in meiner Datenbank das Problem, dass ein und die selbe Telefonnummer mehr als einmal in der Datenbank drin stehen kann.

z.B.
1. Hans Müller als Kunde mit Telefonnummer
2. Hans Müller als Ansprechpartner seiner Firma mit Privatnummer
3. Hans Müller als Ansprechpartner seiner 2. Firma mit Privatnummer
usw....

Sollte nun unser Telefon klingeln, und Hans Müller ruft von seinem Privattelefon an, wird's spannend

[Furtbichler]

Namen sind nicht eindeutig, Telefonnummern schon (eher).

Ich sagt bereits, das dein Vorschlag als Notbehelft zu gebrauchen ist. Aber nur, wenn die Telefonnummern geeignet abgelegt ist. Und was ist morgen?

Konkret: Dein Vorschlag wird umgesetzt und alle sind zufrieden, denn er funktioniert für die aktuelle Problemstellung: Suche nach vollständiger(!) Telefonummer über die derzeit gespeicherten Nummern (die z.B. nach E.123 abgelegt sind).

Morgen werden jedoch die Outlook-Kontakte importiert und dort wird die Telefonnummer nach dem MS-Standard abgelegt, also [phone] (in der DB sind sie jedoch im Format [phone] abgelegt. Ja und dann ruft Hans Müller an, seine Nummer 03012345678 erscheint im Display und deine Suche findet -nichts-. Der Sachbearbeiter kann den Kunden nicht zuordnen und legt ihn im schlimmsten Fall neu an.

Irgendwann wird dann vergessen, das die Lösung erstens nicht immer das korrekte Ergebnis anzeigt, zweitens nur taugt, wenn man die zu suchende Telefonnummer vollständig angibt und drittens doch nur mit einem bestimme Format funktioniert, also eben z.B. nur E.123, aber nicht mit anderen Standards. Und spätestens dann ist die Suche keine Suche sondern ein Glücksspiel.

Deine Lösung zeigt also nicht nur zu viele an (was zu verschmerzen wäre), sondern ist leider unzuverlässig. Und damit imho so nicht zu gebrauchen.

PS: Mein Beispiel funktioniert auch, wenn die Nummern nur im MS-Format abgelegt sind, also mit internationaler Vorwahl, jedoch ohne führende Null in der Ortsvorwahl. Denn es gibt generell mindestens vier unterschiedliche Formatgruppen, die hinsichtlich der einfache Suche disjunkt sind:
Ortsvorwahl: (30) vs. (030).
Landeskennzahl: +49 vs. 0049 vs. ganz weglassen.

Wie Du siehst, wird es nie zuverlässig funktionieren, so elegant und kurz dein Vorschlag auch ist.

Ein Suchalgorithmus muss robust gegen alle Kombinationen sein, d.h. er muss die gespeicherten und die Such-Telefonnummer in LKZ, OnKZ und Rufnummer unterteilen und dann vergleichen.

Richtig richtig macht man es imho nur dann, wenn die Telefonnummern normalisiert abgelegt werden. Alles andere ist Murks.