Re: WHERE über alle Felder
Ich würde mal sagen, das das ein gutes Beispiel für ein falsches Tabellendesign (in Bezug auf die Abfrageanforderung) ist.
Damit ein DB-Server nicht unnötig ausgebremst wird, sollten die durchzusuchenden Felder indiziert sein. Falls ein 'LIKE' Operator verwendet werden muss, sollte kein Escape-Zeichen *vor* dem Suchstring auftreten, um die Suche mit Hilfe eines Indexes zu ermöglichen. Dazu kann man mehrere Indexe erstellen, eines für jedes durchzusuchende Feld, oder man befolgt die die Grundregeln des DB-Designs, und erstellt eine separate Tabelle 'SearchFields' mit drei Feldern: Einem Link zum Masterdatensatz in der ursprünglichen Tabelle, Einem mit dem Inhalt, sowie eventuell noch Einem, das die Unterscheidung ermöglicht, ob es sich um das ursprüngliche 'Feld1', 'Feld2'... handelt. Dann reduziert sich die Abfrage auf
SQL-Code:
Das ist bei einem Index auf SearchFields.Value optimal schnell.
select *
from Tabelle1 alias T1 join SearchFields alias SF on SF.IDMaster = T1.ID where SF.Value = 'FooBar%' |
Re: WHERE über alle Felder
Hi,
Zitat:
Dank dir auf jedenfall schonmal! |
Re: WHERE über alle Felder
Zitat:
naja hier etwas bildlicher:
SQL-Code:
Die zweite Tabelle könnte man hernehmen um den Suchwerten noch bestimmte Gruppen oder anderen Werte zu geben, die man beim Suchen als Einschränkung hernehmen könnte. Sozusagen ein Minihauch Metadaten in dem abstraken Beispiel.
SELECT Feld1
,Feld2 ,FeldBlaBla FROM HauptTablle WHERE ID in (SELECT LinkAufHauptTabelle FROM SuchTabelle WHERE WertInDemGesuchtWerdenKann like :SuchAusdruck) |
Re: WHERE über alle Felder
Zitat:
ist es so hinterlegt :
Delphi-Quellcode:
oder so :
Herr XY
z.Hd. Frau XY
Delphi-Quellcode:
Der Sucher wirds nicht mehr wissen. Er weiß nur, daß irgendwas mit XY vorhanden sein muß. In der Anrede oder eben im Namen. Also muß ich sowieso alle relevanten Adressfelder durchsuchen. Konkateniere ich nun das Ergebnis, dann sind die Originalfelder egal. Die Adresse wird auf jeden Fall gefunden !
Herr
XY z.Hd. Tipse Die Theoretiker werden wohl auch bemängeln, daß LIKE, %, dazu noch vorne und hinten im Suchbegriff usw. langsamer ist als die Felder mit OR zu überprüfen. Das Wort Index ist ja bereits gefallen. Wenn ein Enduser allerdings den XY-Typ innerhalb von 10 Sek. findet, dann ist ihm das wohl viel lieber, als sich 1 Min. einen richtigen Suchbegriff auszudenken und dann 8,8 Sekunden zu warten, um gesagt zu bekommen, daß nichts gefunden wurde, weil das falsche Feld durchsucht wurde. |
Re: WHERE über alle Felder
@Hansa: Es geht hier nicht um Zeitunterschiede von 1,2 Sekunden, wie Du so schön (aber falsch) süffisant angemerkt hast, sondern um drastische Geschwindigkeitsgewinne: Während die Suche über mit Hilfe eines Indexes, unabhängig von der Tabellengröße, in etwa konstant bleibt, wächst der Suchaufwand ohne Index linear: Doppelte Tabellengröße = Doppelte Suchzeit. Wenn man nur mit Tabellen von einigen Tausend Einträgen arbeitet, ist es wirklich egal, aber bei einigen Hunderttausend Einträgen macht sich das schon bemerkbar. Dann beträgt der Zeitunterschied etwa das 100 bis 1000-fache. Eine einfache Suche per Index ist in einigen 100 ms durchgeführt, während die sequentielle Suche ohne Index durchaus Minuten, wenn nicht sogar Stunden dauern kann.
Im Übrigen sind meinen Kunden Suchzeiten von 10 Sekunden nicht egal. Ein solches Schneckentempo erreiche ich höchstens bei Summierungen, ansonsten verlange ich von meiner DB, das die Suchergebnisse *sofort* erscheinen. Ein DB-Server sollte nicht suchen, sondern finden. 10 Sekunden... :wall: Ich würde zwei Tabellen nehmen: Aus einer Tabelle T1: int ID string Name string Feld1 string Feld2 string Feld3 werden zwei Tabellen T2: int ID string Name und SearchFields: int IDT2 int sfCode string FieldValue Ein Datensatz in T1 (1,'MyName','MyField1','MyField2','MyField3') wird auf ein Feld in T2 sowie drei Felder in SearchFields aufgeteilt: T2:(1,'MyName') SearchFields: (1,1,'MyField1') (1,2,'MyField2') (1,3,'MyField3') Und eine Suche in einem der Felder reduziert sich dann auf das bereits beschriebene:
SQL-Code:
Mit einem Index auf den SearchFields.FieldValues hast Du eine Recherchemöglichkeit, die ohne Verzögerung das Ergebnis liefert.
select *
from T2 join SearchFields alias SF on SF.IDT2 = T2.ID where SF.FieldValue ='MySearch' |
Re: WHERE über alle Felder
Hallo,
man muss das Problem übrigens nicht in mehrere Tabellen zerlegen, folgendes geht, zumindest mit FB1.5 auch:
SQL-Code:
Über Performance kann ich leider nichts sagen, da ich hier nicht soviele Daten habe.
create view SuchAnschrift (
KUNDENNO, ANSCHRIFT ) AS select adr.KUNDENNO, adr.ANSCHRIFT1 from woreadr adr where adr.ANSCHRIFT1 is not null union select adr.KUNDENNO, adr.ANSCHRIFT2 from woreadr adr where adr.ANSCHRIFT2 is not null union select adr.KUNDENNO, adr.ANSCHRIFT3 from woreadr adr where adr.ANSCHRIFT3 is not null ; mfg wo |
Re: WHERE über alle Felder
:shock:
OK.. also nachdem ihr jetzt teilweise eine Nacht darüber geschlafen habt und einige vielleicht sogar Albträume hatten.. Welche Version ist denn jetzt am Effektivsten um in ALLEN Feldern einer Tabelle nach einem Teilstring zu suchen? :gruebel: |
Re: WHERE über alle Felder
Wenn Du in ALLEN Felder einer Tabelle nach etwas suchen willst, dann ist die Tabelle falsch designed. Punkt. Denn wenn ich in mehreren Feldern etwas suchen will, enthalten diese semantisch äquivalente Inhalte, ergo gehören diese Felder in eine separate Tabelle.
Erzeuge eine Detailtabelle, wie vorher beschrieben. Alles Andere ist Rumgefrickele. Wenn du allerdings nur ein paar hundert Datensätze hast, lohnt es den Aufwand nicht. Suche dann in allen Feldern durch OR verknüpft. Ob die indiziert sind, oder nicht, ist dann auch egal. Vermutlich wird das DBMS die Indexe gar nicht verwenden. Bei vielen Records musst Du es richtig machen (Detailtabelle), sonst wird der DB-Server unnötig ausgebremst. Dessenungeachtet ist es *immer* am Besten, man probiert es aus. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:08 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz