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