SQL - Alle Felder durchsuchen

[Robin]

Hi @all,

Weiss zufällig jemand ob man der sich mit SQL auskennt wie man mehrere Felder mit einer syntax ansprechen kann. Also folgendes Bsp:

SELECT * FROM kundendaten WHERE vorname LIKE '%$suchstring%' AND nachname = '%$suchstring%' AND ... das könnte jetzt ewig so weitergehen.

Meine Frage ist ob es eine verkürzte Schreibweise dafür gibt.

thx 4 read, cya, RObin.

[Cheatah]

Hi,

SELECT [...] nachname = '%$suchstring%'

"LIKE", nicht "=".

Meine Frage ist ob es eine verkürzte Schreibweise dafür gibt.

Du könntest die einzelnen Spalten stringverknüpfen, allerdings kannst Du dann keinen (normalen) Index mehr verwenden (naja, geht bei LIKE eh nicht, ist also per se ineffizient). Welcher Operator dafür verantwortlich ist, hängt von Deinem DBMS ab. Allgemein ist das Bedürfnis nach einer derartigen Funktionalität ein fast sicheres Zeichen für ein schlecht durchdachtes DB-Layout; prüfe, ob Dein DBMS effizientere Möglichkeiten zur Verfügung stellt, etwa einen Volltext-Index.

Cheatah

[MatzeA]

Servus,

SELECT [...] nachname = '%$suchstring%'

"LIKE", nicht "=".

Meine Frage ist ob es eine verkürzte Schreibweise dafür gibt.

Du könntest die einzelnen Spalten stringverknüpfen, allerdings kannst Du dann keinen (normalen) Index mehr verwenden (naja, geht bei LIKE eh nicht, ist also per se ineffizient). Welcher Operator dafür verantwortlich ist, hängt von Deinem DBMS ab. Allgemein ist das Bedürfnis nach einer derartigen Funktionalität ein fast sicheres Zeichen für ein schlecht durchdachtes DB-Layout; prüfe, ob Dein DBMS effizientere Möglichkeiten zur Verfügung stellt, etwa einen Volltext-Index.

Auf den index würde ich aber nach Möglichkeit verzichten. sowas kann den Performance Todesstoss für Deine DB bedeuten.

Wenn Deine suche über mehrere Tabellen geht würde ich die suche ohnehin nicht über alle Felder auf einmal machen.
Auch das kann Deiner DB den Todestoss versetzen.
Während Du in einem Fall eventuell mehrere millionen Einträge durchsuchst, könnte das jemanden der wirklich nur eine Kleinigkeit in der DB ändern möchte erheblich bremsen.

Sowas gefällt keinem Benutzer.

Gruss Matze

[Klaus Mock]

Hallo,

Auf den index würde ich aber nach Möglichkeit verzichten. sowas kann den Performance Todesstoss für Deine DB bedeuten.

Meinst Du jetzt, dass man Indizes nicht einsetzen soll?
Wenn dem so ist, so hast Du imho ein wesentliches Konzept von Datenbanken nicht verstanden. Indizes sind dafür da, dass man sie (sinnvoll) verwendet, um Suche und Verknüpfungen zu beschleunigen. Wenn Du sie nicht verwendest, würde jede Suche und jeder Join auf alle beteiligten Tabellen einen Zugriff auf alle Daten in den beteiligten Tabellen (Full-Table-Scan) nach sich ziehen. Gerade wenn viele Datensätze vorhanden sind könnte das 'den Todesstoss für die DB', wie Du es ausdrückst, bedeuten.

Natürlich soll man nicht über alles Denkbare Indizes legen, da sonst die Performance beim Modifizieren der Daten leidet. Der sinnvolle Aufbau von Indizes ist imho übrigends eine der wichtigsten Arbeiten eines Datenbankdesigners, gleich nach dem Tabellendesign.

Grüße
  Klaus

[Tom]

Hallo,

<altklug>ich habe noch kein DBMS gesehen, dass pro Tabelle beliebig viele Indexe zulässt</altklug>

Wieviel lässt denn MySQL in der aktuellen Produktivversion zu?

Spannend ist nicht nur die Anzahl der Indexe, sondrn auch deren Tiefe, also die Anzahl der indizierten Zeichen eines Feldes oder eine Feldgruppe.

Grüßle

Tom

[MatzeA]

Servus,

Auf den index würde ich aber nach Möglichkeit verzichten. sowas kann den Performance Todesstoss für Deine DB bedeuten.

Meinst Du jetzt, dass man Indizes nicht einsetzen soll?

Ein schlaues Buch (Oracle Tuning | Verlag Oracle) hat mir mal gesagt,  Indiziere Character Felder nur dann wenn es anderster nicht geht.
Genau dann, wenn Du Strings suchst um einen Einstieg zu bekommen.
Genau dann wenn es keine andere Möglichkeit gibt als exakt nach dem Sring zu suchen. Und dann auch nur dann, wenn man sehr oft drauf zugreift.

Weil genau dann machen Indizierte Character Felder Sinn.

Wenn dem so ist, so hast Du imho ein wesentliches Konzept von Datenbanken nicht verstanden. Indizes sind dafür da, dass man sie (sinnvoll) verwendet,

Richtig sinnvoll -> Laut Oracle Handbuch möglichst selten.

um Suche und Verknüpfungen zu beschleunigen. Wenn Du sie nicht verwendest, würde jede Suche und jeder Join auf alle beteiligten Tabellen einen Zugriff auf alle Daten in den beteiligten Tabellen (Full-Table-Scan) nach sich ziehen. Gerade wenn viele Datensätze vorhanden sind könnte das 'den Todesstoss für die DB', wie Du es ausdrückst, bedeuten.

Ja genau ein Beginner kann nun einschätzen, welche Auswirkung schlechte Indizierung auf eine DB haben kann. ?!?

Eine derarteige suche ist ebenfalls schlecht. Aber wer was beim DB Design denkt, wird vermeiden, mehrere Tabellen zu indizieren und packt es in eine Tabelle zusammen. So gut es eben geht.

Und Du hast grundsätzlich das Konzept eines Sinnvollen DB Designs nicht verstanden richtig?
Denn dann wüsstest du, das ein Fulltable Scan nur beim Select oder in der where Klausel zum tragen kommt.
Aber auch das kann man eingrenzen, indem man weitere Auschlusskriterien verwendet. Sehr Sinnvoll übrigens, damit man nicht zufällig mehrere Einräge findet, die in einer Spalte die gleichen Werte haben. Z.B: bei einem Delete oder Update.

Dass man beim Zugriff auf die DB möglichst nicht nach Strings suchen sollte sondern schlauerweise wo immer es geht mit IDs arbeiten soll, wüsstest Du dann auch. Der Performance gewinn durch Verwendung numerischer IDs ist enorm.

Eine schlechte Indizierung wiederum bremst bei jedem Update Delete Insert der betreffenden Tabellen.

Davon abgesehen, dass dies Teilweise eine DB unnötig zumüllt.
Und wie man eine Suchmenge sinnvoll eingrenzt z.B. mit der Verwendung von Numerischen ID`s dürfte Dir klar sein.

Von daher ist die Inizierung von Character Felder auf das nötigste zu beschränken es gibt bessere und effizentere optimierungs Möglichkeiten.

Natürlich soll man nicht über alles Denkbare Indizes legen, da sonst die Performance beim Modifizieren der Daten leidet. Der sinnvolle Aufbau von Indizes ist imho übrigends eine der wichtigsten Arbeiten eines Datenbankdesigners, gleich nach dem Tabellendesign.

»»

Ja genau und daher weiss der DB Designer, dass er sein Design so wählt, dass er um die Indizierung möglichst herum kommt.

Gruss Matze

[Klaus Mock]

Hallo,

Ja genau ein Beginner kann nun einschätzen, welche Auswirkung schlechte Indizierung auf eine DB haben kann. ?!?

Das verstehe ich nicht.

Eine derarteige suche ist ebenfalls schlecht. Aber wer was beim DB Design denkt, wird vermeiden, mehrere Tabellen zu indizieren und packt es in eine Tabelle zusammen. So gut es eben geht.

Hmm, soll das bedeuten, wir schmeissen den ganzen relationalen Kram weg und arbeiten wieder mit Flat-Tables?

Und Du hast grundsätzlich das Konzept eines Sinnvollen DB Designs nicht verstanden richtig?

Hmm, da sag' ich jetzt nichts dazu;-)

Denn dann wüsstest du, das ein Fulltable Scan nur beim Select oder in der where Klausel zum tragen kommt.

... wobei Abfragen (also die Dingens mit dem SELECT vorne) in der Regel öfter als Modifikationen (damit meine ich INSERT, UBDATE und DELTE Statements) erfolgen.

Aber auch das kann man eingrenzen, indem man weitere Auschlusskriterien verwendet. Sehr Sinnvoll übrigens, damit man nicht zufällig mehrere Einräge findet, die in einer Spalte die gleichen Werte haben. Z.B: bei einem Delete oder Update.

Meinst Du jetzt die Sache mit UNIQUE CONSTRAINTS? Dann muß ich Dich leider enttäschen, denn UNIQUE CONTRAINTS bauen immer einen sog. UNIQUE INDEX auf.

Dass man beim Zugriff auf die DB möglichst nicht nach Strings suchen sollte sondern schlauerweise wo immer es geht mit ID`s arbeiten soll, wüsstest Du dann auch.

Wer glaubst DU, wird jemals nach einem Thread mit der ID 61588 suchen, wenn er etwas von MatzeA oder über 'Alle Felder durchsuchen' lesen will?

Und ich dachte mir die letzten Jahre, dass moderne Programme die Anwender nicht mehr dazu zwingt, sich irgendwelche Kennnummern merken zu müssen.
Nein, ernsthaft, die meisten Suchanfragen auf Datenbanksysteme erfolgen über Strings. ID-Felder, vor allem wenn sie automatisch  generiert werden (sei es durch AUTOINDEX oder SEQUENCES oder vergleichbares), bleiben dem Benutzer meist sowieso verborgen, da sie nur zufällige Zahlenwerte darstellen.

Der Performance gewinn durch Verwendung numerischer ID`s ist enorm.

Das mag schon stimmen, und für Joins auch praktikael sein, aber bei Suchanfragen kannst Du, wie oben hffentlich ausreichend begründet, auf Textsuche nicht verzichten.

Eine schlechte Indizierung wiederum bremst bei jedem Update Delete Insert der betreffenden Tabellen.

Klar, und daher sollte man die Vor- und Nachteile in jedem einzelnen Fall sorgfältig prüfen.

Von daher ist die Inizierung von Character Felder auf das nötigste zu beschränken es gibt bessere und effizentere optimierungs Möglichkeiten.

genau, au das nötigste. Aber herzugehen und komplett darauf verzichten ist genauso falsch.
Ein Beispiel: Wenn Du eine Personendatenbank anlegst, dann wirst du mit Sicherheit nach dem Namen einer Person suchen wollen. Daher ist es sinnvoll, den Namen auch zu indizieren. Hast Du in der Personentabelle noch ein Bemerkungsfeld, kann es durchaus sein, dass eine Indizierung des Bemerkungsfeldes nicht nötig ist, weil Du gar nicht danach suchen willst/kannst.
Aber auf eine Suche nach dem Namen einer Person kannst Du nie und nimmer verzichten.

Ja genau und daher weiss der DB Designer, dass er sein Design so wählt, dass er um die Indizierung möglichst herum kommt.

Das glaube ich nicht, Tim ..äh.. MatzeA;-)

Grüße
  Klaus

[MatzeA]

Hi,

Ja genau ein Beginner kann nun einschätzen, welche Auswirkung schlechte Indizierung auf eine DB haben kann. ?!?

Das verstehe ich nicht.

Gemessen am Design und an der Frage: Stufe Ich den Fragesteller nicht als Freak ein.
Deswegen glaue ich, dass er ncht einschätzen kann welche Fatale folgen eine schlechte Indizierung hat.

Eine derarteige suche ist ebenfalls schlecht. Aber wer was beim DB Design denkt, wird vermeiden, mehrere Tabellen zu indizieren und packt es in eine Tabelle zusammen. So gut es eben geht.

Hmm, soll das bedeuten, wir schmeissen den ganzen relationalen Kram weg und arbeiten wieder mit Flat-Tables?

»»

Nein natürlich nicht. Aber Indizieren von vielen Tabellen, weil die zu durchsuchenden Spalten auf viele Tabellen verteilt
sind, ist deutlich schlechter.

Und Du hast grundsätzlich das Konzept eines Sinnvollen DB Designs nicht verstanden richtig?

Hmm, da sag' ich jetzt nichts dazu;-)

Denn dann wüsstest du, das ein Fulltable Scan nur beim Select oder in der where Klausel zum tragen kommt.

... wobei Abfragen (also die Dingens mit dem SELECT vorne) in der Regel öfter als Modifikationen (damit meine ich INSERT, UBDATE und DELTE Statements) erfolgen.

Rihtig aber man sucht nach möglichkeit nah ID`s.

Aber auch das kann man eingrenzen, indem man weitere Auschlusskriterien verwendet. Sehr Sinnvoll übrigens, damit man nicht zufällig mehrere Einräge findet, die in einer Spalte die gleichen Werte haben. Z.B: bei einem Delete oder Update.

Meinst Du jetzt die Sache mit UNIQUE CONSTRAINTS? Dann muß ich Dich leider enttäschen, denn UNIQUE CONTRAINTS bauen immer einen sog. UNIQUE INDEX auf.

Das ist aber ur dann, wenn der Herr Müller einmal vorkommen darf.
Dann ist es eine überschaubare eingegrenzte Grösse und für die DB nicht mehr zu schlimm, wenn die anzahl der
Inhalte begrenzt ist. Bei einem Union ist die grösse meistens sehr übersichtlich.

Dass man beim Zugriff auf die DB möglichst nicht nach Strings suchen sollte sondern schlauerweise wo immer es geht mit ID`s arbeiten soll, wüsstest Du dann auch.

Wer glaubst DU, wird jemals nach einem Thread mit der ID 61588 suchen, wenn er etwas von MatzeA oder über 'Alle Felder durchsuchen' lesen will?

»»

Dann nicht aber in der Liste wirst Du wohl de Link keinen String hinterlegen um dann wieder nach diesem zu suchen?
Das oben war der einstieg den ich meinte.

Das könnte dann wie folgt aussehen.

Table message (ID Number(1000), MESSAGE_TXT VARCAR(2) )

In der suchst Du um einen Einstieg zu bekommen.
Alles andere also den weiteren Zugriff auf die Messages wirst Du aber wenn du mal eine Liste erhalten has aber über die ID
Lösen oder nicht?

Diese Forum ist aber ein schlechter Vergleich da hier die Meldungen in Textform physikalisch auf der Platte liegen.

Und ich dachte mir die letzten Jahre, dass moderne Programme die Anwender nicht mehr dazu zwingt, sich irgendwelche Kennnummern merken zu müssen.
Nein, ernsthaft, die meisten Suchanfragen auf Datenbanksysteme erfolgen über Strings. ID-Felder, vor allem wenn sie automatisch  generiert werden (sei es durch AUTOINDEX oder SEQUENCES oder vergleichbares), bleiben dem Benutzer meist sowieso verborgen, da sie nur zufällige Zahlenwerte darstellen.

Natürlich präsentiert man dem Benutzer keine ID aber im hintergrund arbeitet man trotzdem damit.
Um obiges Beispiel nochmas zu nehmen.
Dem Link wirst Du von mir aus die href="xyz.de/cgi-bin/thread.php?id=123456" setzen Der Value also was dr Benutzer sieht wird
aber Zweifelsohne ein Text sein. Die Überschrift.

Der Performance gewinn durch Verwendung numerischer ID`s ist enorm.

Das mag schon stimmen, und für Joins auch praktikael sein, aber bei Suchanfragen kannst Du, wie oben hffentlich ausreichend begründet, auf Textsuche nicht verzichten.

Richtig und Du dürftst jedoch erkannt haben, dass die suche nach Strings partu nur an wenigen stellen wirklich zum tragen kommt.
Nämlich dann wenn der Benutzer im Archiv was sucht.

Bei dem Verhalten der Benutzer hier jedoch wirst Du sicherlich bemerkt haben, dass die mehr Posten
als im Archiv suchen :-))

Eine schlechte Indizierung wiederum bremst bei jedem Update Delete Insert der betreffenden Tabellen.

Klar, und daher sollte man die Vor- und Nachteile in jedem einzelnen Fall sorgfältig prüfen.

»»

Richtig von daher überlase ich das nicht dem Benutzer, der gerade mal anfängt mit DB`s zu werkeln.
Ich zitiere nochmals das Oracle Handbuch.

Die Folgen einer schlechten Indizierung sind deutlich grösser als das Vergesen einer derarten Indizierung an einer guten Stelle.
Ein Rücksetzen oder Rücknahme solcher Indizes jedoch ist meistens wegen dem hohen Aufwand nicht mehr zu erledigen.

Von daher ist die Inizierung von Character Felder auf das nötigste zu beschränken es gibt bessere und effizentere optimierungs Möglichkeiten.

genau, au das nötigste. Aber herzugehen und komplett darauf verzichten ist genauso falsch.

Habe ich nicht gesagt.
Möglichst darauf zu verzichten.
Dass heisst für mich nur dann wenn es wirklich sein muss.

Ein Beispiel: Wenn Du eine Personendatenbank anlegst, dann wirst du mit Sicherheit nach dem Namen einer Person suchen wollen. Daher ist es sinnvoll, den Namen auch zu indizieren. Hast Du in der Personentabelle noch ein Bemerkungsfeld, kann es durchaus sein, dass eine Indizierung des Bemerkungsfeldes nicht nötig ist, weil Du gar nicht danach suchen willst/kannst.
Aber auf eine Suche nach dem Namen einer Person kannst Du nie und nimmer verzichten.

»»

Auch richtig. Aber Du wirst niemals den Umfang und Inhalt In einer Benutzer DB haben, dass es wirkich so besonders viel bringt.
Andererseits bremst eine indizierung an der Stelle auch nicht höllisch ab.
Das liegt einfach daran, dass 1. keine hunderttausend Benutzer in der User Table liegen werden.
(Ich schliesse mal Ausnahmen wie Yahoo | AOL | gmx ..... aus)
Aber ich glaube in der riege befinden sich die wenigstens von uns.

und 2. ein Benutzernahme auch nicht vergleichsweise lang wie eine Posting ist.

Ja genau und daher weiss der DB Designer, dass er sein Design so wählt, dass er um die Indizierung möglichst herum kommt.

Das glaube ich nicht, Tim ..äh.. MatzeA;-)

Du könntest mal wieder Dein Flanellhemd bügeln gehen AL der super dupi DB Designer dessen Mutter..... ;-))

Doch siehe oben Tabelle Message

Gruss Matze

[Klaus Mock]

Hallo,

und 2. ein Benutzernahme auch nicht vergleichsweise lang wie eine Posting ist.

Ach, daher weht der Wind;-) Na klar, einfache Indizes über (ich sag's jetzt einmal salopp) 'MEMO'-Felder machen i.d.R. keinen Sinn. Aber Deine Aussagen haben irgendwie den Eindruck erweckt, dass Indizies über jegliche Text-Spalten (also char, varchar) zu vermeiden sind.

Nochmals in aller Deutlichkeit: Indizes sind nicht böse. Indizes gibt es nur aus einem einzigen Grund, nähmlich um Suchvorgänge in Tabellen zu beschleunigen. Und performante Abfragen sind das tägliche Brot von Datenbanken.

Was nützt es denn wenn ich zwar meine, sagen wir mal 1000 Postings pro Tag, in Rekordtempo in die Datenbank bekomme, aber die 10000 Abfragen über die Postings elendslange dauern.
Um das zu vermeiden haben findige Entwickler von Datenbanksystemen sich etwas einfallen lassen. Das, was dabei rausgekommen ist, haben sie dann Indizes genannt.

Ja genau und daher weiss der DB Designer, dass er sein Design so wählt, dass er um die Indizierung möglichst herum kommt.

Nur um die wirklich sinnlosen. Alle anderen würde ein Datenbankdesigner sogar zwingen vorschreiben.

Grüße
  Klaus

[Daniela Koller]

Hi Cheatah

Du könntest die einzelnen Spalten stringverknüpfen, allerdings kannst Du dann keinen (normalen) Index mehr verwenden (naja, geht bei LIKE eh nicht, ist also per se ineffizient).

Das stimmt so allgemein nicht. Der Index kann bis zum ersten Wildcard benutzt werden.

Gruss Daniela