Projekt in Planung: Effektives abspeichern von hoher Anzahl von Zeichenketten

agredo

Cadet 2nd Year
Registriert
Juni 2015
Beiträge
24
Guten Tag liebe Community,

ich plane momentan ein Projekt (C#), welches meine Textdokumente, darunter PDFs, E-Books u.ä., durchsucht.

Die Idee: Stichwort eingeben und die Ausgabe gibt an, welches Dokument das gesuchte Wort auf welcher Seite enthält. Es ist mir bewusst, dass es schon Programme gibt, die dieses tun, aber ich mache es aus Interesse und zu Übungszwecken.

Jetzt stehe ich vor der Frage, welches die effektivste Methode ist, diese Wörter als Zeichenkette zu speichern, um sie daraufhin zu durchsuchen.

Eine Idee war, XML-Dokumente zu erstellen, welche mir eine Art Wörterbuch erstellen.
Jedes Wort als XML-Element enthält als Child-Elemente Bücher, diese jeweils wieder Child-Elemente der Seiten, auf denen das Wort steht.


Jetzt stelle ich mir die Frage, ob diese Methode sinnvoll ist.
Was haltet ihr als Vollprofies davon?
Habt ihr bessere Vorschläge? Datenbank? Andere Dateiformate? Oder was ganz anderes?

Vielen Dank für eure Hilfe.

Agredo
 
Auch wenn Du es selbst entwickeln möchtest, so ist es kein Fehler, sich die Grundlagen dazu anzusehen und zu schauen, wie es 'die großen' machen. Beim Lesen Deiner Frage ist mir sofort Apache Lucene eingefallen. Dort kann man auch in den Source gucken, wenn gewünscht. Hier gibt es ein paar Grundlagen zu Volltextsuchen, die schlussendlich dann an Apache Lucene gezeigt/implementiert werden.

Ein paar Informatiker-Kenntnisse hast Du, oder?
 
Ergänzung ()

HominiLupus schrieb:
XML ist eine sehr blödsinnige Lösungsidee für dieses Problem.

https://en.wikipedia.org/wiki/Inverted_index

Vielen Dank für die Antwort. Ich habe mir in der letzten Nacht ein wenig die Theorie dazu angesehen. Ich bin mir aber noch nicht sicher, wie ich dieses sinnvoll Speicher. Wird das in Textdokumente gespeichert und als "indizierte Datei" benannt, oder gibt es dafür direkt Dateiformate, welche für diese Problematik definiert wurden?
 
Faust2011 schrieb:
* Überflüssiges Zitat editiert! *

Danke dir für die Antwort. Bin da ganz deiner Meinung, da sich die "Großen" als Vorbild zu nehmen.
Wie sind Informatiker Kenntnisse gemeint? Theoretische Informatik steckt bei mir in den Kinderschuhen. Habe mich, bezogen auf dieses Projekt, über gewisse Such- und Sortiertheorien in Bücher Informiert.
 
Zuletzt bearbeitet von einem Moderator:
Du denkst zu speziell, abstrahiere die Sache etwas. Intuitiv scheinst du schon das richtige zu denken :)

Der effizienteste Algorithmus wäre wenn du die Wörter als Index nimmst und hinter dem Index die Dateien aufführst.

Dies ist ein Hash mit einer worst case Laufzeit von O(n), d.h. Wort befindet sich ganz hinten und du musst über alles drüber um es zu finden. Die mittlere Laufzeit ist so im Schnitt was man meist hat, also n/2. Best case ist wenn es ganz vorne steht, dann brauchst genau eine Abfrage.

Weiter optimieren lässt sich dies wenn du den Wörter Index nach Muster sortierst.
Dies wäre dann eine Baumartige Struktur mit einer Laufzeit von O(log(n)) oder besser, d.h. nach jedem Schritt halbiert sich die Datenmenge die man abklappern muss.

Wie man das macht ?
Statt die Wörter direkt als Hash zu nutzen, unterteilst du es weiter.
A-Z in den Hash als key. Der Value ist dann wieder ein Hash.

Dessen Keys sind dann die Wörter mit dem passenden Anfangsbuchstaben, die Values sind dann die Seiten wo man die Wörter findet. Man sucht also erst nach dem Anfangsbuchstaben, dann nach dem Wort und bekommt dann sein Ziel.

Du kannst den Kram noch weiter unterteilen, z.B. Aa bis An als Key, und Ao bis Az.
Wenn du dir das aufmalst bekommst du einen Baum. Sinnvoll ist es in der Mitte des Alphabets zu starten und links alles kleiner, rechts alles größer, damit wird es noch mal scheller, da man von Anfang an nur die Hälfte der Buchstaben betrachten muss (bei mittlerer Laufzeit).

Kompliziert wird es, weil man dann erst mal wissen muss welche Wörter mit welchem Anfangsbuchstaben wie häufig in der Deutschen Sprache auftauche...d.h. von Sprache zu Sprache kann der gleiche Alogrithmus langsamer/schneller sein. Und genau deswegen ist solcher Optimierungskram ein Fach für sich, es ist extrem hart die beste Durchschnittslösung zu finden ! Umso weiter man gräbt umso mehr findet man - am Ende suchst du Studien zur Verteilung der Wörter, nur um so eine Datenhaltung zu bauen :D

Code:
           N
        M     O

Diese Hashes, also Bäume, kannst du wunderbar in allen möglichen Strukturen abbilden.
Vom Datenbank Aufbau bis hin zum XML Aufbau ist alles drin. Ein Hash ist halt nur das was innerhalb der Programmiersprache als einfaches Mittel geboten wird.

Wobei man sagen muss, dass auch eine XML Datei erst eingelesen werden muss, bevor man navigieren kann. D.h. im Prinzip könntest du auch einen Hash in eine Datei serialisieren und ihn dann wieder beim nächsten Programmstart laden. Wäre womöglich sogar schneller weil man nicht erst noch die Tags parsen muss. XML ist dann wieder kompatibel zu allen Programmiersprachen... :)

Und genau ab hier machen Datenbanken Sinn. Die sind für solche Prozesse optimiert, da sie nicht nur die Daten abfragen, sondern auch oft abgefragte Daten automatisch cachen, d.h. man muss gar nicht erst suchen ! Und jede brauchbare Programmiersprache hat APIs um mit den Datenbanken zu interagieren !

Muss auch keine online Datenbank sein, SQLite oder sowas geht auch, das speichert die Daten in Dateien ab. Mit Datenbanken sollte auch jeder Programmierer umgehen können. Du müsstest dann deine XML Gedanken auf Tabellen ummünzen...
 
Zuletzt bearbeitet von einem Moderator:
agredo schrieb:
Danke dir für die Antwort. Bin da ganz deiner Meinung, da sich die "Großen" als Vorbild zu nehmen.
Wie sind Informatiker Kenntnisse gemeint? Theoretische Informatik steckt bei mir in den Kinderschuhen. Habe mich, bezogen auf dieses Projekt, über gewisse Such- und Sortiertheorien in Bücher Informiert.

Ich habe Dir einen Link genannt, der Kenntnisse der theoretischen Informatik voraussetzt (Datenstrukturen, speziell Bäume, Indizes, ausbalancierte Bäume, ...) und genau da bist Du ja fit. Passt also alles :)
 
Green Mamba schrieb:
Was spricht gegen eine Datenbank? ;)

Ich denke mal in einer Ideensammlung zunächst nichts. :) Nur habe ich mich gefragt, ob es für das simple Zeichenkettensortieren doch eine Nummer zu groß ist. :)
Ergänzung ()

rob- schrieb:
Du denkst zu speziell, abstrahiere die Sache etwas. Intuitiv scheinst du schon das richtige zu denken :)

Der effizienteste Algorithmus wäre wenn du die Wörter als Index nimmst und hinter dem Index die Dateien aufführst.

Dies ist ein Hash mit einer worst case Laufzeit von O(n), d.h. Wort befindet sich ganz hinten und du musst über alles drüber um es zu finden. Die mittlere Laufzeit ist so im Schnitt was man meist hat, also n/2. Best case ist wenn es ganz vorne steht, dann brauchst genau eine Abfrage.

Weiter optimieren lässt sich dies wenn du den Wörter Index nach Muster sortierst.
Dies wäre dann eine Baumartige Struktur mit einer Laufzeit von O(log(n)) oder besser, d.h. nach jedem Schritt halbiert sich die Datenmenge die man abklappern muss.

Wie man das macht ?
Statt die Wörter direkt als Hash zu nutzen, unterteilst du es weiter.
A-Z in den Hash als key. Der Value ist dann wieder ein Hash.

Dessen Keys sind dann die Wörter mit dem passenden Anfangsbuchstaben, die Values sind dann die Seiten wo man die Wörter findet. Man sucht also erst nach dem Anfangsbuchstaben, dann nach dem Wort und bekommt dann sein Ziel.

Du kannst den Kram noch weiter unterteilen, z.B. Aa bis An als Key, und Ao bis Az.
Wenn du dir das aufmalst bekommst du einen Baum. Sinnvoll ist es in der Mitte des Alphabets zu starten und links alles kleiner, rechts alles größer, damit wird es noch mal scheller, da man von Anfang an nur die Hälfte der Buchstaben betrachten muss (bei mittlerer Laufzeit).

Kompliziert wird es, weil man dann erst mal wissen muss welche Wörter mit welchem Anfangsbuchstaben wie häufig in der Deutschen Sprache auftauche...d.h. von Sprache zu Sprache kann der gleiche Alogrithmus langsamer/schneller sein. Und genau deswegen ist solcher Optimierungskram ein Fach für sich, es ist extrem hart die beste Durchschnittslösung zu finden ! Umso weiter man gräbt umso mehr findet man - am Ende suchst du Studien zur Verteilung der Wörter, nur um so eine Datenhaltung zu bauen :D

Code:
           N
        M     O

Diese Hashes, also Bäume, kannst du wunderbar in allen möglichen Strukturen abbilden.
Vom Datenbank Aufbau bis hin zum XML Aufbau ist alles drin. Ein Hash ist halt nur das was innerhalb der Programmiersprache als einfaches Mittel geboten wird.

Wobei man sagen muss, dass auch eine XML Datei erst eingelesen werden muss, bevor man navigieren kann. D.h. im Prinzip könntest du auch einen Hash in eine Datei serialisieren und ihn dann wieder beim nächsten Programmstart laden. Wäre womöglich sogar schneller weil man nicht erst noch die Tags parsen muss. XML ist dann wieder kompatibel zu allen Programmiersprachen... :)

Und genau ab hier machen Datenbanken Sinn. Die sind für solche Prozesse optimiert, da sie nicht nur die Daten abfragen, sondern auch oft abgefragte Daten automatisch cachen, d.h. man muss gar nicht erst suchen ! Und jede brauchbare Programmiersprache hat APIs um mit den Datenbanken zu interagieren !

Muss auch keine online Datenbank sein, SQLite oder sowas geht auch, das speichert die Daten in Dateien ab. Mit Datenbanken sollte auch jeder Programmierer umgehen können. Du müsstest dann deine XML Gedanken auf Tabellen ummünzen...

Danke dir für die ausführliche und kompetente Antwort. Meine erste Idee war auch eine Datenbank (SQLite) zu Nutzen. War aber nicht sicher, ob dieses nicht für ein solches Problem zu umfangreich ist. Aber aus diesem Grund habe ich mich ja auch an euch gewendet. Also werde ich mich in den von Faust2011 geposteten Link einlesen und mich mal über Hashes ausgiebig Informieren.
Hast du denn da Grundsätzlich eine Empfehlung, welche Lösung du an meiner Stelle verwenden würdest?
Ergänzung ()

overflow schrieb:
Mit PHP (voller DOS-Zugriff, stellt auch zip files her) ein Klacks ;-)

Leider bin ich dem PHP nicht mächtig ;)
 
Zuletzt bearbeitet:
Ach Hashes sind einfach, da brauchst nichts groß lernen.

Zum üben kannst ja einen Hash befüllen, diesen dann verarbeiten und in XML umwandeln.
Mach paar Trockenübungen, dann richtig. Dann noch eine umgekehrte Funktion, XML zum Hash.

Also so dass das Programm intern mit Hashes arbeitet, aber in XML speichern und laden kann.
Das wird dich zwingen auch mit String Funktionen umzugehen :)

Gibt auch noch DOM für C# , ist eine API mit der du XML verarbeiten/erstellen kannst. Aber ist nicht ganz ohne da durchzublicken, erfordert Wissen über Bäume usw.
 
Zuletzt bearbeitet von einem Moderator:
Danke für die Hilfe ich werde mich mit euren Tipps mal an die Arbeit machen :)
 
Hallo :) ich habe nun erst mal versucht eine fertige Datenbank zu nutzen. Habe da an SQlite gedacht.

ich habe mich daran nun versucht. habe mich da an das Video: https://channel9.msdn.com/Series/A-Developers-Guide-to-Windows-10/10 gehalten.

Code:
public sealed partial class MainPage : Page
     {

         public SQLiteConnection conn { get; set; }
         public MainPage()
         {
             this.InitializeComponent();

             LoadDatabase();
             InsertDatabaseContent();

         }

         private void LoadDatabase()
         {


             conn = new SQLiteConnection("myDatabase.db");

             string sql = @"CREATE TABLE IF NOT EXISTS
                                                 Customer   (Id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
                                                             Name    VARCHAR ( 140 ),
                                                             City    VARCHAR ( 140 ),
                                                             Contact VARCHAR ( 140 ))    ";


             using (var statemant = conn.Prepare(sql))
             {
                 statemant.Step();
             }

             /*sql = "CREATE VIRTUAL TABLE enrondata1 USING fts3(content TEXT)";
             using (var statemant = conn.Prepare(sql))
             {
                 statemant.Step();
             }
 */


         }

         private void InsertDatabaseContent()
         {
             using (var custstmt = conn.Prepare("INSERT INTO Customer (Name, City, Contact) VALUES (?, ?, ?)"))
             {
                 custstmt.Bind(1, "Christian");
                 custstmt.Bind(2, "Musterstadt");
                 custstmt.Bind(3, "Musterstr.");
                 custstmt.Step();

             }
         }

     }

Nun habe ich mich daran gemacht habe eine Kleine Datenbank erstellt mit einfachen Einträgen. Nun verstehe ich nicht, wie ich eine Volltextsuche in c# erstelle. Ein versuch ist auskommentiert.

Vielen dank im Voraus

Agredo
 
Ganz einfach: gar nicht! Sorry, aber immer wenn ich sowas höre, dann dreht sich mir der Magen um. Du nutzt hier für Dein Problem das falsche Tooling. Hast Du eigentlich meinen Post #3 gelesen? Genau für solche Sachen nutzt man bspw. Apache Lucene :rolleyes:
 
Schau dir mal in Ruhe Lucene an http://lucenenet.apache.org/
Der Link führt dich zur Lucene Searchengine geschrieben in C#.Net. Den Quellcode kannst du dir anschauen!

Zu deinem Ansatz: Ich sehe, dass du quasi noch bei null stehst. Mach dir mal Gedanken über Folgendes.
1. Du brauchst eine Datenstruktur in der du deine Daten abspeicherst
2. Du brauchst eine Logik, die dir den Text extrahiert, aufbereitet und dann in die Datenstruktur schreibt
3. Du brauchst eine Logik, die dir deine Suchanfrage aufbereitet, dann in der Datenstruktur sucht und dir die Ergebnisse mitteilt

Hier mal so ein paar Ideen, wie man es besser nicht machen sollte:

A) Theoretisch könntest du eine relationale Datenbank dafür nehmen, den gesamten Text in eine Tabelle werfen und dann mit Standard SQL in diesen Texten suchen lassen:
MYDOCS(FILENAME, MYTEXT)
Für die Suche im Text wirst du dann wahrscheinlich den LIKE Operator benutzen, z.B.
Code:
SELECT * FROM MYDOCS WHERE MYTEXT LIKE '%blablub%'
Soweit so gut, ABER diese Suche ist nur bei sehr wenigen Einträgen in der Datenbank relativ schnell, sobald du viele Datensätze hast, wird es sehr langsam. Die Suche kannst du auch nicht durch Nutzung eines normalen Index optimieren!

B) Theoretisch könntest du 3 Tabellen erstellen:
DOCS (DOC_ID, FILENAME) -> hier werden alle Dateien/Dokumente, die du indiziert hast, eingetragen
KEYWORDS(KEYWORD_ID, KEYWORD) -> hier wird je ein Eintrag pro Schlüsselwort gemacht
HITS(DOC_ID, KEYWORD_ID) -> hier landen nun die Verknüpfungen von Schlüsselwort zu Dokument
Nun müsstest du deine Dokumente scannen, die Dokumente in DOCS eintragen, den Text extrahieren, den Text in Schlüsselwörter zerteilen, die Schlüsselwörter in KEYWORDS eintragen mit den beiden IDs dann die HITS Tabelle füllen. Zur Suche würdest du dann sowas schreiben, wie z.B.
Code:
SELECT *
FROM DOCS A
JOIN HITS B ON A.DOC_ID=B.DOC_ID
JOIN KEYWORDS C ON B.KEYWORD_ID=C.KEYWORD_ID
WHERE C.KEYWORD = 'blablub'
Soweit so gut, ABER du hast dann mit folgenden Problemen zu kämpfen:
1. Die Performance ist aufgrund der JOINS alles andere als gut.
2. Eine Suche nach einer exakten Zeichenkette wie z.B. 'Benutze lieber Lucene zur Volltextsuche' ist nicht mehr möglich.
3. Du musst eine mehr oder weniger gute Logik finden um deinen Text zu parsen. Dieser Parser kann auch dazu führen, dass technische Bezeichnungen oder Ids im Text, wie z.B. Artikelnummern, Bestellnummern, nicht gesucht werden können, weil diese einfach zerstückelt wurden. Beispiel: Dein Parser trennt den Text nach jedem Leerzeichen und Sonderzeichen. Dann werden mal aus "0815/123" schnell "0815" und "123" als Schlüsselwörter generiert. Genauso Datumsangaben: "31.12.2014" würde zu "31", "12" und "2014" führen. Die Suche nach dem Datum kannst du damit vergessen. Auch zusammengesetzte Wörter wie, z.B. "e-Mail" werden dann mal eben zu "e" und "Mail". Bei der Suche musst du deinen Parser dann ebenfalls über die zu suchenden Begriffe drüberjagen und aus dem Ergebnis deine Suchanfrage generieren, weil du sonst nichts finden wirst.
4. Stemming: Wäre es nicht schön, dass wenn du nach "fahren" suchst, dann auch "fährt" oder "fuhr" findest? Genauso nach "Straße" suchen und dann auch Treffer für "Strasse","Straßen", "Strassen" finden? Das kannst du beim einfachen splitten der Texte zur Schlüsselwortgenerierung vergessen. Hier muss wieder extra Logik rein, die das beim Einlesen der Dokumente umsetzt und dann auch bei der Suche vor der Suchabfrage aus den Suchbegriffen generiert.
5. ...

Das sind mal nur so 2 Lösungen die man als Anfänger vielleicht mal verfolgen könnte, die aber letztendlich nicht zum Ziel führen werden, da sie so viele Probleme in sich haben, dass es schlicht nicht einsetzbar wird. Deswegen nochmal der Tip von mir, wie es dir auch Faust schon empfohlen hat, schau dir was von den Großen an, wie z.B. Lucene, statt was eigenes zu backen mit dem du nicht glücklich wirst. BTW: Oracle und MS SQLServer unterstützen auch Volltext Indizes, die man auch für eine Volltextsuche nehmen könnte. Bleibt nur noch dein Problem mit Anzeige der Seitenzahl/Abschnitt in dem die Suchwörter vorkommen ...
 
Zuletzt bearbeitet:
@Faust2011 natürlich habe ich den Post gelesen. Hier wird nichts umsonst geschrieben ;)

@Rossibaer ich danke dir für die Ausfürhliche hilfe:)

Ich habe da nur eine Frage. Vielleicht verstehe ich auch grundsätzlich was falsch und bin euch daher sehr Dankbar für die Geduld:)

Ich habe mir gedacht SQlite zu nutzen, da ich in meiner Naiven Art gedacht habe dass eine Volltextsuche bereits implementiert wurde.

Code:
Overview

FTS3 and FTS4 are SQLite virtual table modules that allows users to perform full-text searches on a set of documents. The most common (and effective) way to describe full-text searches is "what Google, Yahoo, and Bing do with documents placed on the World Wide Web". Users input a term, or series of terms, perhaps connected by a binary operator or grouped together into a phrase, and the full-text query system finds the set of documents that best matches those terms considering the operators and groupings the user has specified. This article describes the deployment and usage of FTS3 and FTS4. 

FTS1 and FTS2 are obsolete full-text search modules for SQLite. There are known issues with these older modules and their use should be avoided. Portions of the original FTS3 code were contributed to the SQLite project by Scott Hess of Google. It is now developed and maintained as part of SQLite. 

1. Introduction to FTS3 and FTS4

The FTS3 and FTS4 extension modules allows users to create special tables with a built-in full-text index (hereafter "FTS tables"). The full-text index allows the user to efficiently query the database for all rows that contain one or more words (hereafter "tokens"), even if the table contains many large documents. 

For example, if each of the 517430 documents in the "Enron E-Mail Dataset" is inserted into both an FTS table and an ordinary SQLite table created using the following SQL script: 


CREATE VIRTUAL TABLE enrondata1 USING fts3(content TEXT);     /* FTS3 table */
CREATE TABLE enrondata2(content TEXT);                        /* Ordinary table */

 

Then either of the two queries below may be executed to find the number of documents in the database that contain the word "linux" (351). Using one desktop PC hardware configuration, the query on the FTS3 table returns in approximately 0.03 seconds, versus 22.5 for querying the ordinary table. 


SELECT count(*) FROM enrondata1 WHERE content MATCH 'linux';  /* 0.03 seconds */
SELECT count(*) FROM enrondata2 WHERE content LIKE '%linux%'; /* 22.5 seconds */

 

Of course, the two queries above are not entirely equivalent. For example the LIKE query matches rows that contain terms such as "linuxophobe" or "EnterpriseLinux" (as it happens, the Enron E-Mail Dataset does not actually contain any such terms), whereas the MATCH query on the FTS3 table selects only those rows that contain "linux" as a discrete token. Both searches are case-insensitive. The FTS3 table consumes around 2006 MB on disk compared to just 1453 MB for the ordinary table. Using the same hardware configuration used to perform the SELECT queries above, the FTS3 table took just under 31 minutes to populate, versus 25 for the ordinary table.

Quelle: http://sqlite.org/fts3.html

Also Funktioniert das nicht so, dass ich diese Volltextsuche nutzen kann, sonder muss dann auf externe Searchengines wie Apache Lucene setzen?

Vielen Dank im Voraus

Agredo :)
 
Zuletzt bearbeitet:
Natürlich kannst du auch die Volltextsuche / Indizierung deines Datenbankmanagementsystems (DBMS) verwenden. Ist auf jeden Fall besser als auf naive Art das ganze selbst zu implementieren. Das von dir geschriebene Beispiel ist ähnlich dem was die Volltextindizes von Oracle und SqlServer machen. Das ist aber nunmal ganz spezifisch für dein DBMS. Wie genau es funktioniert, musst du dann recherchieren. Bei deinem Beispiel funktioniert wohl nicht das Anlegen der virtuellen Tabelle mit fts3? Wenn ja, was für ein Fehler kam da? Welche Probleme hast du damit? Fehlermeldungen sind hilfreicher als einfach die Aussage "Das geht nicht" ...

Lucene wäre unabhängig von einem DBMS, genau genommen hat es auch soetwas wie seine eigene DB integriert, die nicht extra installiert werden muss. Ist halt deine Entscheidung wie du das mit der Volltextsuche machen willst, entweder du nimmst ein ausgewachsenes DBMS und nutzt dessen Features oder du nimmst eine Suchengine wie Lucene. Da bist du völlig frei.

BTW: Bei deinem Beispiel erzeugst du erstmal eine "normale" Tabelle "Customer" und versuchst dann im auskommentierten Code diese virtuelle Tabelle zu erzeugen. Was hat das eine mit dem anderen zu tun? Was willst du damit bezwecken?
 
Da das Feature fts3/fts4 auf der Seite von SQlite als Extension angegeben ist, wollte ich ausprobieren, ob ich es tatsächlich so einfach implementieren kann. Es hat zumindest keinen Fehler verursacht.
Nun stehe ich vor dem Problem dass ich wirklich nichts gefunden habe, wie ich diese Suche sinnvoll implementiere. Ab besten wäre ein Tutorial für c#. Ein Sample Code für c# würde es ja auch tun, aber ich finde nichts.

In dem Beispiel von der Seite wird ein Table erzeugt. Aber wie befülle ich diese?
CREATE VIRTUAL TABLE enrondata1 USING fts3(content TEXT);
 
Code:
-- virtuelle Tabelle für Volltextsuche anlegen mit den Spalten filename und content
CREATE VIRTUAL TABLE documents USING fts3(filename, content);

-- Befüllen der Tabelle
INSERT INTO documents(filename, content) VALUES('MeineDatei.pdf', 'Inhalt der Datei ... blablub');

-- Abfragen der Tabelle
SELECT * FROM documents WHERE content MATCH 'blablub';

Das kannst du in einem SQL Abfragetool deines Vertrauens mal ausführen und schauen was passiert...

Danach musst du nur noch diese SQL Befehle in C# anwenden. Schau mal da http://blog.tigrangasparian.com/2012/02/09/getting-started-with-sqlite-in-c-part-one/
 
Zurück
Oben