Volltextsuche in Blob möglichst schnell

[Teekeks]

Doch, es gibt einen Unterschied: Ich kann keinen Varchar mit z.B. 10000 Zeichen anlegen! Wenn ich dies Versuche, bekomme ich folgende Nachricht:

Zitat:

Dynamic SQL Error
SQL error code = -204
Data type unknown
Implementation limit exceeded
COLUMN TEST

Ich habe mal mit dem Like rumgespielt (das hatte ich ganz vergessen dass es das gibt ^^)
Dabei herrausgekommen ist folgendes:

Code:

SELECT Count(*) FROM PE_REZEPTE a WHERE a.Text like '%Fenchel%' and a.nummer=2

Kann ich dass jetzt für eine Nummer auch auf mehrere Begriffe ausweiten? Also das ich nicht nur nach "Fenchel" suche sondern auch z.B. nach "Banane"?
Weil jetzt wird ja nur zurück gegeben ob der eine Begriff da ist oder nicht, wobei sich Count ja momentan auf die anzahl der zurückgegebenen Datensätze (also ja Maximal 1 wegen dem eindeutigen Feld Nummer) bezieht.

Liege ich da jetzt mit meinen Gedankenwegen auf dem richtigen Weg oder soll ich doch anders vorgehen?

Danke schon einmal für eure Hilfe bis hierhin!

[mkinzler]

Eigentlich sollte die Beschränkung bei 32768 sein. Ab Firebird 2.1 werden Textblobs unterhalb dieser Grenze sowieso wie ein VARCHAR-Feld behandelt.

[Teekeks]

Hmmm gut. Wir haben schon mal Firebird 2.1 am laufen.
Zeichensatz ist UTF8.
Wie viele sind den dort maximal möglich?
Laut einem Text von 2006 ist da maximal etwa 10000 Zeichen möglich, aber auch schon 4000 schlagen ja fehl.

[mkinzler]

Die Begrenzung ist wie gesagt 32765. Bei Firebird >=2.5 wird dann auch ein Textblob der kürzer ist wie ein VARCHAR-Feld behandelt

Zitat:

BLOB Subtype 1 Compatibility with VARCHAR
A. dos Santos Fernandes
(v.2.1) At various levels of evaluation, the engine now treats text BLOBs that are within the 32,765-byte string size limit as though they were VARCHARs. Operations that now allow text BLOBs to behave like strings are:
• Assignments, conversions and concatenations (|| operator)
• Operators = , <>, >, <, >=, <=, BETWEEN, IS [NOT] DISTINCT FROM
• Functions CAST, BIT_LENGTH, CHAR[ACTER]_LENGTH, OCTET_LENGTH, LEFT, RIGHT, HASH, LOWER, UPPER, LPAD, RPAD, TRIM, OVERLAY, REPLACE, POSITION, REVERSE, MINVALUE, MAXVALUE, SUBSTRING
• Existential predicators IN, ANY/SOME, ALL • Search predicators CONTAINING, STARTING [WITH], LIKE
• A LIST expression. Note that, prior to v.2.1.4, the last part of the result may be truncated, an effect that applies to native VARCHAR columns also.

[Teekeks]

Woran liegt es dann aber das ich bei diesem SQL-Befehl:

Code:

ALTER TABLE PE_REZEPTE ADD 
test Varchar(10000);

Diese Fehlermeldung bekomme?

Zitat:

Dynamic SQL Error
SQL error code = -204
Data type unknown
Implementation limit exceeded
COLUMN TEST

Könnte das vl an Flamerobin liegen (mit diesem Programm lege ich die Felder an).
Irgendeinen Grund muss das doch haben dass es normalerweise geht, aber hier nicht.

Gruß Teekeks

[FredlFesl]

Hmmmm. vielleicht solltest du einen anderen Ansatz wählen. Teile den Text doch in Wörter auf und schmeiss die Wörter in eine separate Tabelle: Jedes Wort bekommt dabei einen Verweis auf den Originaltext, bzw. seinen PK.

Dann kannst Du in der Worttabelle sehr schnell suchen, sofern du nach Wörtern bzw. dem Wortanfang suchst. Wenn Du dann noch die Wortposition mit speicherst (also das wievielte Wort im Text es ist), kannst Du sogar nach Inhalten suchen... Dann dürfen die gesuchten Worte nicht zu weit voneinander entfernt sein, d.h. die Wortpositionen sind z.B. < 10 oder so.

Auf 32k-Begrenzungen würde ich mich nicht einlassen, denn eine Beschränkung auf einer derart atomaren Ebene ist ein Designfehler.

[mkinzler]

Ich hab es mal in IBExpert getestet. Hat problemlos funktioniert. Scheint also ein Problem von FlameRobin zu sein.

Zitat:

Hmmmm. vielleicht solltest du einen anderen Ansatz wählen ...

Nennt man Volltextindex und wurde schon als mögliche Lösung benannt.

Zitat:

Auf 32k-Begrenzungen würde ich mich nicht einlassen, denn eine Beschränkung auf einer derart atomaren Ebene ist ein Designfehler.

Diese Aussage verstehe ich nicht ganz.
Erstens sind die meisten Texte kürzer.
Zweitens kann man bei längerer Texten ja eine Textblob verwenden, dann existiert keine Beschränkung ( höchtens der Größe der Festplatte)
Bei Firebird >=2.1 würde ich auf jeden Fall einen Blob verwenden, weil man dann die Vorteile beider Implementierungen nutzen kann (siehe oben)

[Teekeks]

Eigendlich reicht mir das Blob ja.
Und es wird ja sowieso als VarChar behandelt. In so fern sollte dass ja dann auch egal sein.
Ich habe ja schon weiter oben einen Teilansatz gefunden, aber irgendwie war meine Frage dann untergegangen.
Jetzt also noch mal:

Zitat:

Code:

SELECT Count(*) FROM PE_REZEPTE a WHERE a.Text like '%Fenchel%' and a.nummer=2

Kann ich dass jetzt für eine Nummer auch auf mehrere Begriffe ausweiten? Also das ich nicht nur nach "Fenchel" suche sondern auch z.B. nach "Banane"?
Weil jetzt wird ja nur zurück gegeben ob der eine Begriff da ist oder nicht, wobei sich Count ja momentan auf die anzahl der zurückgegebenen Datensätze (also ja Maximal 1 wegen dem eindeutigen Feld Nummer) bezieht.

Noch einmal danke für eure rege Beteiligung an der Diskussion!

[mkinzler]

Du kannst natürlich per OR mehrere Suchen kombinieren. Aber ohne einen Index wird das dann nicht gerade performant sein.