Konzept einer Datenbanksuche

[deitysou]

Hallo,

ich wollte mal fragen, ob ihr Ideen für eine gute Datenbanksuche
hab.
Zur Erklärung:
In einem Programm können Kunden nach Daten suchen - wie ungewöhnlich - .<br>
Mit der Zeit wächst so eine Datenbank natürlich und irgendwann hat man viele viele Felder, nach denen ein Kunde suchen könnte.
<br>
Damit man aber nicht für die Suche jedes einzelne Feld extra frei schalten oder einbauen muß, wollte ich mal fragen ob jemand von euch Konzepte kennt um diese Problematik gut abzubilden.
<br>
Lösungsansätze die ich kennengelernt habe machen mich nicht glücklich, da ich nicht einschätzen kann wie gut diese sind.
a) Nach jedem SQL-Statement werden die potentiellen Suchbegriffe
gefiltert und gespeichert. Wird die Suche dann angestoßen, kann direkt in einer eigenen Suchtabelle gesucht werden und anhand der Schlüßel der Datensatz identifiziert werden.
b) Für jedes Feld muß in einem administrativen Bereich dem Programm erklärt werden, wie es an die korrekten Suchbegriffe kommt. Ausgehend von einer Haupttabelle kann man so verknüpfte Werte finden.
Beispiel: Ein Feld "Name" liegt in einer Tabelle B. Die Haupttabelle ist A.
Im administrativen Bereich wird dann festgelegt, wie die Suche aus Tabelle A nach B oder X kommt.<br>
Naja hoffe das ist soweit verständlich.<br>
Meine Frage bezieht sich also darauf, wie man am schönsten eine Datenbanksuche über alle erlaubten Felder gestallten kann.
Am Besten mit Stored Procedures ;D.<br>
Kurze Anmerkung noch: Ich verwende den MS SQL-Server 2000.
Danke für Hinweise.
MfG

[Andreas Kosch]

Hallo,
eine pauschale Antwort ist schwierig, da es (wie immer) auf die konkreten Anforderungen ankommt. Zusätzlich zu den Alternativen a) und b) gibt es jedoch noch die Volltextsuche, die im SQL Server 2000 über den <b>Volltextindizierungs-Assistent</b> aufgebaut wird. Dort kann man eine Sammlung von Tabellenspalten definieren, in denen gesucht werden soll. Zur Suche kommt dann die erweiterte Syntax der Volltextsuche (Bsp: <i>WHERE CONTAINS...</i>) zum Einsatz.
<br>
Die Volltextsuche vereinfacht auch die Umsetzung der Alternative a), da ein Aufsplitten auf bestimmte Suchbegriffe durch das Zusammenstellen einer Zeichenkette mit allen Daten ersetzt wird

[deitysou]

Danke für den Hinweis, ich hatte die Volltextsuche überhaupt nicht als mögliche Variante in Betracht gezogen, zumal ich damit auch noch nicht gearbeitet habe.

Ich werd mir das ansehen. :

[deitysou]

Ich habe mir das jetzt mal angesehen und das ganze klingt sehr gut.
<br>
Wenn ich das richtig verstehe werden Volltextsuchen so optimiert, dass eine normale Transact-SQL-Anfrage mit CONTAINS über die Volltextsuche auf die originalen Tabellen verweisen.
Was eine Optimierung von Textabfragen zur Folge hat.
<br>
Wenn ich das Konzept korrekt interpretiere komme ich um JOIN- und WHERE- Klauseln trotzdem nicht wirklich herum.
Eigentlich optimiert mir die Volltextsuche nur Textabfragen oder habe ich etwas entscheidendes überlesen bis jetzt?
<br>
MfG
und danke nochmals

[Andreas Kosch]

Hallo,
&gt;...die Volltextsuche nur Textabfragen ...

ja, deswegen hatte ich in der vorherigen Antwort auch den Satz "<i>Die Volltextsuche vereinfacht auch die Umsetzung der Alternative a), da ein Aufsplitten auf bestimmte Suchbegriffe durch das Zusammenstellen einer Zeichenkette mit allen Daten ersetzt wird.</i>" untergebracht. Wenn alle durchsuchbaren Vorgangsdaten (Zeichenkette, Datums-Werte, etc) als Zeichenkette verkettet und in einer Spalte abgelegt und mit dem Primärschlüsselwert des originalen Datensatzes als 2. Spalte etikettiert werden, kommt die Volltextsuche auch ohne JOIN aus. Ob diese Option in der Praxis in Frage kommt, hängt immer vom Einzelfall (Gegenüberstellung des Aufwands für die komplexe Einzelfeld-Suche zum Aufwand für die Zusammenkettung der Zeichenkette für die Volltextsuche) ab