Einzelnen Beitrag anzeigen

Rollo62

Registriert seit: 15. Mär 2007
3.926 Beiträge
 
Delphi 12 Athens
 
#8

AW: Was ist die beste Lösung für eine Keywort-Filterung per SQL ?

  Alt 12. Jul 2021, 07:03
Dankesehr für die guten Vorschläge, das zeigt mir das ich nicht ganz falsch liege.

...WHERE (m.IdKeywort IN (SELECT idkey FROM @DeinTableValueParameter))
Sehr interessant, mit variablen TableParametern habe ich noch nichts gemacht, das schaue ich mir mal an.

Und wenn du die Key-Value-Tabelle auch auf dem SQL-Server hast, könnte die SP statt der IDs auch die "echten" Keywords annehmen und die IDs für die WHERE-Klausel aus der Key-Value-Tabelle ermitteln.
Du meinst eine temporäre Tabelle für jede Suche zu Erzeugen, an sowas hatte ich auch schon gedacht, aber
ich hätte Bedenken dass dies doch eher weniger effizient ist als die paar Parameter direkt zu übergeben.


Dann gibt es eine Tabelle Wörter: Sie enthält alle gefundenen Wörter und eine eindeutige ID für das Wort. (Jedes Wort kommt in dieser Tabelle natürlich nur einmal vor.)
Dann könnte das eine Art "Wörterbuch über Alles" werden, wächst das nicht extrem an ?
Auf der anderen Seite hatte ich schonmal vor Jahren mit solchen Text-Wörderbücher gearbeitet, das war durchaus überschaubar von der Größe.
Man benutzt eben doch nicht unendlich viele Kombinationen.
Wie groß wird Dein Wörterbuch denn ?

Per SQL geht die Abfrage in etwa so:

SQL-Code:
select Wörter.Wort, Quelletxte.* from Quelletxte, WortQuelltext, Wörter
where Quelltexte.id = WortQuelltext.QuelltextID
and WortQuelltext.WortID = Wörter.id
and Wörter.Wort in ('eins',zwei'drei','ganz','viele',Wörter']
Index auf jede ID und auf die Wörter.
Ja richtig, das "in" ist auch eine sehr gute Alternative für variable Eingaben.


Ist verblüffend schnell und war in 'nem Tag implementiert, kann man analog natürlich auch auf Blob-Spalten, ... anwenden.

...

Achso: Da das so gut geklappt hat, gibt es das inzwischen auch für alle HTML-Seiten (wie z. B. ct-Archive von CDs), diverse Tutorials von anno schlagmichtot, Rezepte,
Dankesehr, das bestätigt ja meine Einschätzung.
Es muss nicht immer ElasticSearch sein, mit dem ganzen Overhead.


Klein? RAM, Platte, CPU? Eine Postgres Installation hat ca. 90MB glaub ich, weit weg von GB Datenfiles, trotzdem natürlich viel mehr als SQLite. Postgres läuft problemlos auf einem Raspberry.
Ich würde das eher über Nutzen und Zugriffe definieren.
Also vielleicht 5 Nutzer, mal Zugriffe 10x pro Woche, also keine große Sache.

Klein bedeutet für mich auch lauffähig auf einem kleinen virtuellen PHP Internet-Host mit REST-Anbindung,
damit es von überall her erreichbar ist.
  Mit Zitat antworten Zitat