nicht angemeldet
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