LIKE mit INTEGER

[study11]

Hi Leute,

ich bin neu hier. Leider hab nichts zum Thema gefunden, deswegen würde mich freuen, wenn mir jemand helfen könnte.

Ich bastel grad eine Suchmaske, wo Benutzer die Suchbedienungen angibt, unter denen dann Select-Anweisung gebildet wird.
Wenn das um die Abfrage von Daten von Typ Char, Varchar usw geht, geht das mit LIKE sehr gut:

Select .... where NAME like 'T%' oder '%k%'

Die Frage ist: wie es mit den Daten von Typ INTEGER oder DATE geht? Kann ich ohne präzise angegebene Telefonnummer eine Telefonnummer finden, die mit z.B. 5 beginnt? Es muss doch irgendwie gehen...

Vielen Dank
Gruß

[Ralf Jansen]

die mit z.B. 5 beginnt?

Ich pack mal gerade wieder meinen inneren Pedanten aus. Ein Integer hat kein Format und kann damit auch nie mit einer 5 beginnen. Wenn du sagst eine Zahl die mit einer 5 beginnt hast du bereits dein mentales Zahlenmodell verwendet das dir einen Zahlenwert in irgendeinem Format (z.b die Dezimaldarstellung einer Zahl als text also einem string) vorgauckelt und dort kann dann eine Zahl mit 5 beginnen. Insofern solltest du das selbe im Code tun wie in deinem Kopf. Die Name Spalte in einen string casten und dann denn like darauf ausführen.

Sollte auf deiner Spalte ein Index gewesen sein und dein Datenbankmodel auch die Verwendung des Indexes bei Like unterstützen so wäre spätestens jetzt das gestorben.

[Jürgen Thomas]

Hallo und willkommen im Forum!

Grundsätzlich ist LIKE dafür nicht vorgesehen: LIKE vergleicht Zeichenketten - basta.

Eine Telefonnummer oder auch eine PLZ ist keine Zahl, sondern eine Zeichenkette, die aus Ziffern und bestimmten Sonderzeichen bestehen kann; also kann LIKE problemlos dafür verwendet werden. Du solltest allenfalls für eine standardisierte Speicherung (z.B. ohne Leerzeichen usw.) sorgen.

Bitte beachte unbedingt auch Ralfs Hinweis: Ein DATE ist ein DATE ist ein DATE. Eine bestimmte Zeichen-Darstellung ist nur eine Form zur Anzeige oder Eingabe, aber sonst nichts.

Um dennoch Zahlen und DATEs o.ä. zu vergleichen, kannst du den Wert mit CAST oder CONVERT (oder, soweit vorhanden, FORMAT) in einen String verwandeln und diesen per LIKE prüfen.

Gruß Jürgen

[study11]

Vielen Dank für eure Hilfe.
Ich verwandel die Daten in einen String und dann vergleiche mit LIKE.

Gruß

[Falk Prüfer]

Hallo,

Ich verwandel die Daten in einen String und dann vergleiche mit LIKE.

Erwarte dabei aber keine Performancerakete. Wenn dein DBMS nicht gerade funktionale Indizes für die "verwandel"-Operation unterstützt, wird bei solchen Suchen ein Full-Table-Scan notwendig, der je nach Menge der Daten eben dauert. Auch bei Konstrukten LIKE '%T%' können die meisten DBMS keinen normalen Index verwenden! Man sollte sich hierbei also genau überlegen was man tut und was tatsächlich notwendig ist, bzw. ob weitere einschränckende Bedingungen angegeben werden können oder ggfs. besser geeignete Suchstretegien für das DBMS zur Verfügung stehen. Stichwort: Volltextsuche

Gruß Falk

[dimitri]

Telefonnummern die als INTEGER abgelegt werden, sind eh etwas "verkorkst" ;-)
089 wird daann zu 89.

[Bernhard Geyer]

Telefonnummern die als INTEGER abgelegt werden, sind eh etwas "verkorkst" ;-)
089 wird daann zu 89.

089 ist ist ja auch keine Telefonnummer

0 = Kennzeichner für Nationalweites Gespräch (Jedenfalls in DE - Manche länger haben z. B. 9 als Kennzeichner
89 = Ortsnetzkennzahl

Da in anderen Ländern unser 0er als Kennzeichen eines überreginalen Rufs z.B. eine 9 ist kann es dort (lokale) Rufnummern(teile) geben die mit 0 anfangen.
Damit hat man hier genauso wie bei den PLZ das führende 0er Problem.

[tömmel]

089 ist ist ja auch keine Telefonnummer

0 = Kennzeichner für Nationalweites Gespräch (Jedenfalls in DE - Manche länger haben z. B. 9 als Kennzeichner
89 = Ortsnetzkennzahl

Da in anderen Ländern unser 0er als Kennzeichen eines überreginalen Rufs z.B. eine 9 ist kann es dort (lokale) Rufnummern(teile) geben die mit 0 anfangen.
Damit hat man hier genauso wie bei den PLZ das führende 0er Problem.

...trotzdem sind das für mich Zeichenketten - sind nur 'zufällig' alles Ziffern

[dimitri]

089 ist ist ja auch keine Telefonnummer

Aber die Problematik hast Du ja trotzdem erkannt oder?

[Bernhard Geyer]

Aber die Problematik hast Du ja trotzdem erkannt oder?

Klar doch. Muss ja vor über 10 Jahren auch schon mal ein DB-Modell für Rufnummern definieren.

Hätte evtl. den Reply eher Richtung study11 geben sollen.

[study11]

Ja, es ist mir auch klar, dass die Telefonnummer als ZK in DB gespeichert werden soll. Es geht bei mir aber darum, dass ich die Daten aus einem beliebigen view in DB auslesen kann, ohne zu wissen, wie es aufgebaut ist und was für Datentyp ich auslese. Also, den Datentyp muss erstmal erkannt werden, dann Falls es integer ist ....
Das Problem war ja, dass im SQLBase funktioniert CAST, CONVERT usw nicht. Ich habe das so realisiert:

@string(telnr,0) like '5%'; -> für INTEGER, FLOAT,DECIMAL ...

@Datetochar(geburtsdate,'dd-mm-yy') like '01%'; -> für DATETIME, TIME ...

jetzt hab ich ne Frage bezüglich LONG VARCHAR?
und zwar: wie kann ich die long varchar - Daten in die Tabelle einfügen?
Beim Insert :
insert into table( long_var_column) values ('Hallo-o')
sehe ich die Meldung:
" Long must be set to bind variable "
versteh nicht, wieso muss sie bind variable sein?

Gruß

[Ralf Jansen]

LONG VARCHAR ist vermutlich irgendeine Sorte BLOB Datentyp. Da kann man in vielen (gerade nicht mainstream) Datenbanken nicht einfach die Standard SQL Methoden darauf anwenden sondern muss je nach Context auf irgendwas DB abhängiges ausweichen.

Die Frage nach dem wieso wird dir hier kaum einer beantworten können. Das kann nur jemand vom Hersteller und da vermutlich auch nur ein technischer Mitarbeiter. Hier kann dir maximal jemand bestätigen das man dass muss. Die Wahrscheinlichkeit einen weiteren SQLBase User zu finden halte ich auch für eher gering.

[study11]

Danke Ralf.
Du hast Recht. Es gibt wenige ((