nicht angemeldet
BCNF
Hallo,
ich habe eine ziemlich riesige Datenbank in die Boyce Codd Normalform gebracht und jetzt stellt sich mir folgende Frage:
Die zentrale Tabelle mit den Verknüpfungen in alle Untertabellen besteht nur aus Zahlenwerten (int). Ist es sinnvoll für jedes Attribut einen Index zu erstellen wegen der schnelleren Durchsuchung oder ist das ein Schuss in den Ofen, weil die Größe der Tabelle dadurch zu stark aufgebläht wird, so daß die Suche nicht mehr so schnell abläuft?
Ohne Indexierung aller Attribute hat sie eine Größe von 24 MB.
Mit Indexierung aller Attribute hat sie eine Größe von 70 MB.
Grüße, Matthias
-
yo,
Die zentrale Tabelle mit den Verknüpfungen in alle Untertabellen besteht nur aus Zahlenwerten (int).
der begriff untertabellen ist mir neu und ich wüßte auch nicht, was damit gemeint ist. auch wundert mich das datendesign ein wenig, dass eine tabelle alle anderen verbinden soll, was aber sicherlich möglich ist. aber ohne genaue kenntnisse des daten-designs läßt sich das schwer abschätzen. vielleicht kannst du es ja noch mal nachreichen.
Ist es sinnvoll für jedes Attribut einen Index zu erstellen wegen der schnelleren Durchsuchung oder ist das ein Schuss in den Ofen, weil die Größe der Tabelle dadurch zu stark aufgebläht wird, so daß die Suche nicht mehr so schnell abläuft?
das kann man so pauschal nicht beantworten. indexe auf "teufel komm raus" zu erstellen ist sicherlich nicht sinnvoll. wichtig dabei sind deine DML befehle und vor allem deine abfragen an die datenbank. typische kandidaten für einen index sind zum beispiel attribute, die in der WHERE klausel oder JOIN bedingung vorkommen. primary keys besitzen schon einen index, insofern braucht man dafür keinen mehr zusätzlich zu erstellen. auf der anderen seite spielt auch die kardinalität und die anzahl der datensätze eine rolle. du siehst, so einfach ist die frage nicht zu beantworten.
Ilja
-
Die Boyce Codd Normalform ist so definiert, das in keiner Tabelle mehr transitive Abhängikeiten vorkommen dürfen, das heißt jedes Attribut in der "Haupttabelle" ist nach der Auflödung ein Fremdschlüssel einer anderen Tabelle. Diese "anderen Tabelle" haben meist nur noch zwei Attribute, das Indizierungsattribut und den eigentlichen Wert.
Also minimale Redundanzen.
In der Haupttabelle stehen also nur noch Fremdschlüssel und die sind logischer Weise als int deklariert.
Um mit den Daten arbeiten zu können sind natürlich viele, z.T. sehr umfangreiche Abfragen mit NATURAL JOIN nötig.
-
Hi,
Die Boyce Codd Normalform ist so definiert, das in keiner Tabelle mehr transitive Abhängikeiten vorkommen dürfen, das heißt jedes Attribut in der "Haupttabelle" ist nach der Auflödung ein Fremdschlüssel einer anderen Tabelle. Diese "anderen Tabelle" haben meist nur noch zwei Attribute, das Indizierungsattribut und den eigentlichen Wert.
nur mal interessehalber, was machst Du mit Dateumsfeldern und Integer-Feldern (Waehrungsbetraege) zum Beispiel?
Gruss,
Ludger-
Hallo,
Datumsfelder sind ohne Punkt mit auffüllender 0, also z.B:
1.3.2005 --> 20050301
Währung wird in Cents angegeben
Grüße, Matthias
-
Hi,
Datumsfelder sind ohne Punkt mit auffüllender 0, also z.B:
1.3.2005 --> 20050301
Währung wird in Cents angegeben
Du normalisierst Datums- und Waehrungsfelder also nicht?
Gruss,
Ludger
-
-
-
yo,
Die Boyce Codd Normalform ist so definiert, das in keiner Tabelle mehr transitive Abhängikeiten vorkommen dürfen,
dem stimme ich zu, die ersten drei normalformen beziehen sich auf die abhängigkeiten der einzelnen attribute untereinander.
das heißt jedes Attribut in der "Haupttabelle" ist nach der Auflödung ein Fremdschlüssel einer anderen Tabelle.
das wäre mir neu. ich finde weder den begriff "untertabellen" aus deinem ersten post noch "haupttabellen" in bezug auf normalisierung. auch das jedes attribut in der "haupttabelle" ein fremdschlüssel ist, das ist nicht zwangsweise so. diese aussage halte ich für schlicht weg falsch. aber ich kann mich sicherlich auch irren, ein link deinerseits würde helfen. es kann sicherlich durchaus sein, dass in einer beziehungstabelle alle attribute fremdschlüssel andere tabellen sind. ABER das muss nicht zwangsläufig so sein.
Diese "anderen Tabelle" haben meist nur noch zwei Attribute, das Indizierungsattribut und den eigentlichen Wert.
gehe ich recht in der annahme, dass du mit indizierungsattribut den primärschlüssel meinst ?
In der Haupttabelle stehen also nur noch Fremdschlüssel und die sind logischer Weise als int deklariert.
das ist keinesfalls logisch. es gibt auch PK die nicht integer sind, zum beispiel natürliche schlüssel, die unter anderem buchstaben besitzen.
Um mit den Daten arbeiten zu können sind natürlich viele, z.T. sehr umfangreiche Abfragen mit NATURAL JOIN nötig.
nun, unter anderem kommt es genau auf diese abfragen drauf an, um einen sinnvollen index von einem unsinnigen index unterscheiden zu können.
ich will noch mal meine meinung deutlich zum ausdruck bringen. die normalisierung hat nur wenig mit der indezierung zu tun. vielmehr entscheiden ganz andere kriterien. ich befürchte, du versteifst dich dabei ein wenig zu sehr auf die normalisierung. die normalisierung ist ein prozess, der ohne jegliche daten auskommt. aber um herauszufinden, wo man einen index erstellen sollte, dafür braucht man informationen, die mit der normalisierung nichts zu tun haben, z.b. die abfragen, die menge der datensätze, die kardenalität, etc.
Ilja
-
-
-
Hi,
Die zentrale Tabelle mit den Verknüpfungen in alle Untertabellen besteht nur aus Zahlenwerten (int). Ist es sinnvoll für jedes Attribut einen Index zu erstellen wegen der schnelleren Durchsuchung oder ist das ein Schuss in den Ofen, weil die Größe der Tabelle dadurch zu stark aufgebläht wird, so daß die Suche nicht mehr so schnell abläuft?
die Tabelle wird ja nicht groesser, wenn Du Metadaten (Indizes) anlegst. Allerdings werden INSERTs und DELETEs und so schon ein wenig langsamer. Dein Kriterium sollte also sein: werden die Indizes benoetigt?
Und die Antwort lautet: frag den Abfrage-Designer (der weiss naemlich welche Datenfelder ihn besonders interessieren und welche Klauseln (z.B. WHERE, ORDER BY) auf welche Datenfelder zielen)
Gruss,
Ludger -
Servus,
das kommt auf Deine DBMS drauf an.
Je nachdem ist es völlig unnötig da int von den DBMS allgemein recht gut verarbeitet werden verglichen mit Char etc.Aber ob eine indizierung der int Werte eine performance verbesserung bringt hängt von Deiner dbms ab.
Gruss Matze
-
yo,
Je nachdem ist es völlig unnötig da int von den DBMS allgemein recht gut verarbeitet werden verglichen mit Char etc.
warum sollte es einen unterschied zwischen int und char geben ? letztlich liegen beide in binärer form vor
Ilja
-
Seruvs,
war die Frage wirklich ernsthaft gemeint?
Auch wennes Binär vor liegt, sind woh die zu vergleichenden Binären Muster von Ascii Zeichen und nur Zahlen in der grösse (lange) doch deutlich unterschiedliche.Gruss Matze
-
yo,
war die Frage wirklich ernsthaft gemeint?
ja
Auch wennes Binär vor liegt, sind woh die zu vergleichenden Binären Muster von Ascii Zeichen und nur Zahlen in der grösse (lange) doch deutlich unterschiedliche.
das war aber nicht deine aussage, sondern das int werte besser von dem dbms verabreitet werden als char. und das spielt eigentlich keine rolle. ob ich zum beispiel in der where klausel nach einem integer-wert abfrage oder nach einen char-wert spielt für die geschwinsigkeit keine rolle.
Ilja
-
Servus,
für welche Geschwindigkeit spielt es keine Rolle?
Bis das Suchergebniss geliefert wird oder bis die Abfrage vom System angenommen wurde?
Doch es spielt eine Rolle, ob Du nach Chars suchst oder nach Zahlen. Es macht sogar sehr viel aus.
Wenn Du in Character Felder suchst, wird der Binärschlüssel verglichen.
Wenn Du nach Zahlen suchst, wird ein anderer Algomrytmus verwendet.
Select * from tabelle where spalteninhalt = "abcde"
Passiert folgendes.In Charackter Felder wird jeder Datensatz verglichen.
Bei Zahlen wird eine geordnete Liste erzeugt.Und dann passiert folgendes.
Select * from tabelle where suchspalte = 1024
Nehmen wir an wir haben 100 Datensätze.
Dann wird "idealerweise" * der erste und letzte Satzt geprüft. Treffen diese nicht zu, wird der 50. Satz geprüft kleiner oder grösser oder = Suchwert.
Je nachdem wird weiter gesucht. Dann entweder bei 25 usw.
Hol man den Taschenrechner raus.
Im Bereich von etwa spätestens 10 Wertvergleichen erhält man das Ergebnis.Bei Character muss jeder der Datensätze verglichen werden.
Was schneller ist, dürfte klar sein oder?
Allerdings wurde an dem Algorytmus gefeilt und geschliffen, so das diese Form kaum noch Verwendung findet.Das schlimmste ist, wenn Du nur Teile eines Strings sucht. also mit like.
Natürlich lässt sich obige Methode auch teilweise für die Eingrenzung der Suchmenge verwenden. Aber eben nur eine grobe eingrenzung. Und auc nicht bei jedem Fall der Anfrage.Nehmen wir an, Du suchst bei einer entsprechenden Liste alle Artikel mit Stückzahl 20.
Die Zahlen werden sortiert, mit obiger Methode gelangt man recht schnell zu den Artikel mit 20 als Stückzahl. Man geht jeweils um eines nach oben in der Liste, bis da etwas kleiner als 20 kommt, springe an das unter Ende des ersten Treffers und verfolge die Liste nach unten bis ein Ergebnis grösser als 20 kommt.Versuche nun etwas Binäres aus einer Wurst heraus zu filtern, was man leider so mathematisch nicht mehr beschreiben kann.
Liefer mir alle Artikel welche den Buchstaben a enthalten.
Ball
Haus
Auto
Kerzenständer
Schleifband
Knetmaschiene
Holzofen.
Wankelmotor.Versuch nun diese Binären Zahlen mathematisch so zu ordnen, dass Du genau so eine Reihenfolge bekommst wie oben.
Geht nicht. Das kannst Du leider nicht mathematisch in eine Regel fassen.
Du kommst sicherlich nun mit der Idee.
Aber was ist, wenn ich alle Artikelnummer suche, wo die Zahl 5 drin vor kommt.Das ist eine Character Anfrage und keine Integer Anfrage.
Denn jetzt wird die Zahl, wo Du ermitteln willst zwangsweise zu einem "Wort" character umgewandelt.Im Regelfall musst Du das sogar selbst in deinem SQL tun.
Gruss Matze
-
yo,
Wenn Du nach Zahlen suchst, wird ein anderer Algomrytmus verwendet.
meiner meinung nach gibt es keinen unterschied, wenn ein index vorhanden ist. ansonsten sollte in beiden fällen in aller regel ein full scan durchgeführt werden. sicherlich gibt es ausnahmen, wo ein index on the fly erzeugt wird. auf der anderen seite führt ein dbms manchmal sogar einen ful scan aus, obwohl ein index vornahden ist.
Bei Zahlen wird eine geordnete Liste erzeugt.
das alleine erfordert, das jeder datensatz angefasst wird und somit sollte es auf keinen fall schneller sein. sortierungen sind nicht gerade das, was die performance steigert. dies käme einem order by gleich nur eben nicht über die ergebnismenge, sondern über alle datensätze der tabelle.
Bei Character muss jeder der Datensätze verglichen werden.
nein, nicht bei einem index.
Was schneller ist, dürfte klar sein oder?
nun, das schnellste ist ein vorhandener index der auch benutzt wird und da spielt es keine rolle ob char oder int. und deine sortierte liste läßt mich sehr an der geschwindigkeit zweifeln, zumal es alles nur langsamer macht, wenn sehr viele datensätze der gesuchten bedingung entsprechen. matze, zeig mir einfach mal einen link von einem dbms, dass immer genauso vorgeht, wie du es beschreibst, wenn es sich um zahlen handelt.
Ilja
-
Servus,
Wenn Du nach Zahlen suchst, wird ein anderer Algomrytmus verwendet.
meiner meinung nach gibt es keinen unterschied, wenn ein index vorhanden ist. ansonsten sollte in beiden fällen in aller regel ein full scan durchgeführt werden. sicherlich gibt es ausnahmen, wo ein index on the fly erzeugt wird. auf der anderen seite führt ein dbms manchmal sogar einen ful scan aus, obwohl ein index vornahden ist.
Deine Meinugnin allen ehren, aber ein Index ist dann doch etwas anderes, als ein Umwandeln von Buchstaben in berechenbare Zahlen.
Beim Indizieren werden Fragmente erstellt, di ein suchergebniss schneller eingrnzen lassen. Wie die Fragmente aussehen, liegt jedoch an den Entwicklern der jeweiligen Db selbst. Entsprechend kann es sinnvoll sein oder eben nicht Nummern zu indizieren.
nein, nicht bei einem index.
Stimmt aber, immer noch schlechter als Zahlen das ganze.
Eine indizierung nimmt niimmt als Zuorndung zu den Datensätzen wiederum ID,s die auf integer basieren.Was schneller ist, dürfte klar sein oder?
nun, das schnellste ist ein vorhandener index der auch benutzt wird und da spielt es keine rolle ob char oder int. und deine sortierte liste läßt mich sehr an der geschwindigkeit zweifeln, zumal es alles nur langsamer macht, wenn sehr viele datensätze der gesuchten bedingung entsprechen. matze, zeig mir einfach mal einen link von einem dbms, dass immer genauso vorgeht, wie du es beschreibst, wenn es sich um zahlen handelt.
Diesen link wirst Du so nicht finden. Warum?
Also erstens habe ich es so auch geschrieben, wird dieses Verfahren in einer optimierten Form angewendet.
Das ist jedoch wie die gesammte Umsetzung der Datenverwaltung so geheim, wie das Suppenrezept von Maggi. Denn genau das macht die Datenbank aus und wirst Du so as link wohl nirgens finden. Ausser den Quellcode einer Offenen Datenbank studieren.
Mysql z.B.Online habe ich leider an Doku nichts gefunden.
Vielleicht auch dumm gesucht. Ich habe jedoch ein Offline Buch, das Indizierung recht gut beschreibt und was dort passiert.
Ab Seite 83.Oracle 8 Tuning Von Oracle Press
ISBN 3-446-19464-9Eine weitere Referenz:
expert one on one
Wrox Verlag
ISBN 1-861004-82-6
Kapitel 7 Ab Seite. 270Ist es wunderbar beschrieben, wie es funktioniert. Wie man es anwendet und wo es hacken und ösen dazu gibt.
Auch das Kapitel 2 Architektur beschreibt sehr schon wie die Daten ablegt werden, wie diese Verarbeitet werden usw.
Ich schätze mal, dass Dich meine vielseitigen Aufschriebe aus dem Studium / Vorlesungen hierbei nicht überzeugen werden.
Aber Ich gebe mal zurück gib doch mal Referenzen zu Deiner These ab.
Gruss Matze
-
Hi,
Was schneller ist, dürfte klar sein oder?
nun, das schnellste ist ein vorhandener index der auch benutzt wird und da spielt es keine rolle ob char oder int. und deine sortierte liste läßt mich sehr an der geschwindigkeit zweifeln, zumal es alles nur langsamer macht, wenn sehr viele datensätze der gesuchten bedingung entsprechen. matze, zeig mir einfach mal einen link von einem dbms, dass immer genauso vorgeht, wie du es beschreibst, wenn es sich um zahlen handelt.
Ich schätze mal, dass Dich meine vielseitigen Aufschriebe aus dem Studium / Vorlesungen hierbei nicht überzeugen werden.
Aber Ich gebe mal zurück gib doch mal Referenzen zu Deiner These ab.
Also ich wuerde mich ggf. als Referenz zur Verfuegung stellen. :-)
Allerdings kann ich mir schon vorstellen, dass ein indiziertes INT-Datenfeld doch etwas schneller durchsucht werden kann als ein indiziertes CHAR-Datenfeld.
Schreib doch mal etwas ausfuehrlicher, was Du meinst.
Gruss,
Ludger-
Hi,
Schreib doch mal etwas ausfuehrlicher, was Du meinst.
Es geht darum, dass Datenbanken (eigentlich nicht nur die) grundsätzlich mit Zahlen besser zurecht kommen als mit Chars.
Letzendlich liegt das an mehreren Gründen.
Einer ist, dass wenn man den PC gesammt betrachtet Also von Anzeigenfläche Alphanumerisch bis zur Platte binär bei Zahlen der Rechner diese direkt als binären Wert verarbeitet und umrechnet. Buchstaben hingegen müssen wegen dem 16 / 32 / 64 Bit Format des Prozessors erst mal in einen Numrsichen Wert zerlegt werden, damit es dann in einen Binären Wert zerlegt werden kann.
Bei Zahlen ist dieser Schrit nicht notwendig. Das liegt an der seriellen abarbeitung.
Das Binäre musster wird von recht nach links in das jeweilige Register geschoben.
Die neun wäre also Binär 1001
Ein 16 Bit Register aber 16 stellen lang. (Hoffe blos die Aussage stimmt soo lange nicht mehr so tief in der Eben gedacht)Nur prinzipiell:
Wäre 9 dann: 00 00 00 00 00 00 10 01
Beim schreiben des Wertes genügt es die Vier stellen ins Register zu schieben.
Mehr passiert auch gar nicht. Was nicht gesetzt war, muss hinterher auch nicht auf 0 Zurück gesetzt werden.Das hatte ich bisher noch nicht ewähnt.
Dass für die Suche und die Datenhaltung also in der Anwendungsschicht, wo man nicht mehr Binär arbeitet, unterschiedliche Algorytmen des jeweiligen Datentyps benötigt werden wollte Ich ilija näher bringen. Somit also meine Aussage letzendlich stimmt, dass Zahlen und Buchstaben integer und char unterschiedlich gut "unterstützt" werden.
Somit ist es erklärt, dass char schlicht weg benachteiligt sind.
Deswegen ist es auch "notwendig" diese zu indizieren damit die Suche entsprechnd unterstützt wird. Macht aber nicht immer und grundsätzlich Sinn.Beim blinden indizieren kann man seine DB auch gut ausser gefecht setzen. Das wiederum steht auch in meinen genannten Referenzen.
Darum ging es letzendlich. Das Beispiel meiner Suche und die unterschiede in der char integer suche, waren stark vereinfacht. Aber den genauen algorythmus verrat Dir der Hersteller eine DB wohl äusserst ungern. Denn das macht die Db unter anderem aus.
Und mysql ist nun mal, keine highend und hochperfromante DB in der Massendatenhaltung. Daher ist der dort eingesetzte Algorytmus gut und Zweckmässig.
Ich werd mir jedoch nicht das WE mit Quellcode lesen verbummeln.
Ist auch nicht nötig, um etwas zu Beweisen, was man eigentlich in einer guten Ausbildung lernt.Gruss Matze
-
yo,
Somit ist es erklärt, dass char schlicht weg benachteiligt sind.
Deswegen ist es auch "notwendig" diese zu indizieren damit die Suche entsprechnd unterstützt wird. Macht aber nicht immer und grundsätzlich Sinn.schau mal mätze. mach doch einfach mal einen test und setze einen index auf eine character spalte und dann mach eine abfrage nach einem bestimmten namen. das gleiche machst du auf eine int spalte ohne index und du wirst erkennen, dass bei einer grossen anzahl von datensätze (z.b. 1 million) nicht nur char spalten den sinn von einem index spüren werden. und wenn du dann herausgefunden hast, dass die abfrage nach der char spalte wesentlich schneller abgelaufen ist, trotz aller geheimen und verdunkelten algos auf int werte, dann kannst du ja noch mal einen index auf die int spalte setzen und sehen, inwieweit sich die suche unterscheidet der beiden unterscheidet. beides kann man sicherlich auch machen, ohne das auf beiden ein index existiert.
Und mysql ist nun mal, keine highend und hochperfromante DB in der Massendatenhaltung. Daher ist der dort eingesetzte Algorytmus gut und Zweckmässig.
wenn ich mich nicht ganz täusche, dann rühmt sich mysql gerade damit, besonders schnell zu sein, auch im vergleich mit dbms wie oracle. du solltest einen entsprechende grafik bei mysql dazu finden.
und da du einen link nicht zeigen kannst, nochmal eine frage, wie soll den das dbms eine solche sortierte liste für int werte erstellen, ohne jeden datensatz einmal angefassen zu müssen ?
Ilja
-
Servus,
Also sehr nett Deine Idee habe ich prompt gemacht.
Backup der Datenstämme eines Payback Systemes auf eine Testumgebung gezogen und mal eine Suche über knapp 32 mio Kundendaten geschickt.Bei der Ermittlung der Daten habe ich folgendes gesucht:
Die INT ID die Kontonummer ID sowie die Rabatt Kathegorie.
Alles int.Char bzw. einmal Name Strasse und Ort.
Während bei der Ermittlung der Kontonummer und einer anderen suche nach der ID der Betreffende Datensatz innerhalb 128 ms gefunden wurde, dauerte die Suche nach allen etwa 278 000 Kunden der Kathegorie 25 knapp 512 ms.
Bei der Suche nach den in der Schillerstrasse wohnhaften 84 712 treffern dauerte etwas von 16,8 Sekunden. Bei allen Vornamen mit Martha 7 629 treffer, dauerte die suche knapp 32 Sekunden.
Nach Indizierung der Daternstämme, wobei ich jeweils nur die zu befragende Spalte indizierte, ergaben sich folgende Werte:
120 ms , 492 ms, 3,7 ms sowie 9,4 ms.
Eingesetzes System Solaris 8 / Oracle 10 i
»» wenn ich mich nicht ganz täusche, dann rühmt sich mysql gerade damit, besonders schnell zu sein, auch im vergleich mit dbms wie oracle. du solltest einen entsprechende grafik bei mysql dazu finden.
Das rühmt sich Fox Pro auch. Bei simultanten abfragen und hohen Benutzerzugriffen bröckenln die Zeite rapide. Dann haben verschiedene Datenbanklsysteme ganz schön die Hosen unten.
Es wurde durchaus in erwägung gezogen ein anderes DBMS System zu verwenden.
Mangelnde Funktionalität und die durchaus bei den geforderten Zugriffen nicht erreichbare Performanced hat Oracle siegen lassen.
Gut MS SQL wäre noch eine alternative gewesen sogar die bessere. Man wollte aber kein Windows.und da du einen link nicht zeigen kannst, nochmal eine frage, wie soll den das dbms eine solche sortierte liste für int werte erstellen, ohne jeden datensatz einmal angefassen zu müssen ?
Lies die genannten Bücher da steht es drin.
Beim laden der oder suchen der Integer muss mehr oder minder die DB auch über alle Datensätze drüber. Aber erhält schon beim auslesen eine sortierte Liste, was bei char nicht möglich ist.Damit muss dann beim Suchprozess nicht mehr jede Spalte angefasst werden, sonder es sticht der Zeiger in den mittigsten Datensatz schaut drüber oder drunter.... wie ich es schon beschrieben habe.
Eine Referenz zum nach sehen hast Du ja.
MYSQL. die Kochen auch nur Wasser wie viele Referenzen willst Du noch?
Soll ich aus den knapp 10 MB komprimierten Quellcode noch die stelle raus suchen?Sorry, so wichtig ist es mir nicht dir zu beweisen, dass Ich im Studium und meiner späteren Arbeit Augen und Ohren offen gehalten habe.
Bücher habe ich Dir auch genannt. Hör also auf mit Vermutungen und ich glaube.
Überprüf ob meine Aussage stimmt oder spar Dir Deine Energie zum lernen, wie DBMS Systeme funktionieren.Gruss Matze
-
Sorry,
Tippfehler120 ms , 492 ms, 3,7 s sowie 9,4 s.
Im übrigen es war eine einfache Tabelle mit entsprechend vielen Feldern.
Keine Abhängigkeiten per Femdschlüssel usw.Gruss Matze
-
yo,
Nach Indizierung der Daternstämme, wobei ich jeweils nur die zu befragende Spalte indizierte, ergaben sich folgende Werte:
120 ms , 492 ms, 3,7 ms sowie 9,4 ms.
ich werde noch ein paar tage brauchen, dann kann ich mein oracle dbms bei mir zuhause installieren und es nachprüfen.
Lies die genannten Bücher da steht es drin.
Beim laden der oder suchen der Integer muss mehr oder minder die DB auch über alle Datensätze drüber. Aber erhält schon beim auslesen eine sortierte Liste, was bei char nicht möglich ist.ich glaube kaum, dass ich mir die genannten bücher kaufen/ausleihen werde, nur um deine behauptung nachzuprüfen. wenn es so offensichlich ist, das dbms mit integer besser als mit char umgehen können, dann wirst du wohl einen link ausmachen können, der sich genau darauf bezieht.
Damit muss dann beim Suchprozess nicht mehr jede Spalte angefasst werden, sonder es sticht der Zeiger in den mittigsten Datensatz schaut drüber oder drunter.... wie ich es schon beschrieben habe.
eine unsortierte datenmenge zu sortieren, und das ist eine tabelle, erfordert dass man jeden datensatz anfäßt. zeig mir bitte das gegenteil ohne auf deine bücher zu verweisen.
Ilja
-
Servus,
ich glaube Du hast keine Ahnung vom Thema EOT.
Gruss Matze
-
-
Hi MatzeA
Während bei der Ermittlung der Kontonummer und einer anderen suche nach der ID der Betreffende Datensatz innerhalb 128 ms gefunden wurde, dauerte die Suche nach allen etwa 278 000 Kunden der Kathegorie 25 knapp 512 ms.
Bei der Suche nach den in der Schillerstrasse wohnhaften 84 712 treffern dauerte etwas von 16,8 Sekunden. Bei allen Vornamen mit Martha 7 629 treffer, dauerte die suche knapp 32 Sekunden.
Und jetzt bitte den Test unter fairen Bedingungen wiederholen. Ich hätte gerne bei beiden Sucharten die gleiche Anzahl Treffer im Ergebnis. Ausserdem über einen Integerwert der nicht Primärschlüssel ist (insbesondere kein Autoincrement da diese teilweise durch die Einfügereihenfolge bereits in der richtigen Reihenfolge auf der Platte liegen). Achja, und entweder liegt auf beiden der Spalten ein Index oder auf keiner. Wenn einer vorhanden ist, dann bitte auch mit ähnliche Projektivität.
Gruss Daniela
-
Servus,
Beides mal die gleichen Treffer.... Das wird schwieriger.
Muss mal sehen, was sich da ergibt oder eben ein Testszenario erstellen.Die IDS waren nicht, per autoincrement erstellt worden.
Der Datensatm würde aus einer bestehden Umgebung übernommen, hierbei nur jene Benutzerdaten, welche sich im Zeitraum von 24 Monaten einloggte.Die IDS wurden daher in einer willkührlichen Reihenfolge eingetragen.
Beim Rest der Daten ist es wohl ähnlich.Ich habe jeweils nur die zu durchsuchende spalte indiziert.
Der Test sollte ja beweisen, dass Char nicht so performant
verarbeitet wird, als es integer sind. Dabei möchte ich es ganz geziehlt getrennt betrachten. Bei einer Indizierung beider Tabellen gleichzeitig, könnt hingegen char durch die Integer profitieren.Ich sagte könnte! Eine Fremdbeeinflussung jedoch wollte ich einfach vermeiden.
Ja werde mir, sofern mir die Zeit reicht ein entsprechendes Testszenario
ausetzen und nochmals testen.-> Ich bin mir sicher, dass s trotzdem und weiterhin nachteilig für die Chars ausfällt.
Gruss Matze
-
SCNR,
Ja werde mir, sofern mir die Zeit reicht ein entsprechendes Testszenario
ausetzen und nochmals testen.-> Ich bin mir sicher, dass s trotzdem und weiterhin nachteilig für die Chars ausfällt.
feelings, nothing more than feelings...
Gruss,
Ludger
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Die zentrale Tabelle mit den Verknüpfungen in alle Untertabellen besteht nur aus Zahlenwerten (int). Ist es sinnvoll für jedes Attribut einen Index zu erstellen wegen der schnelleren Durchsuchung oder ist das ein Schuss in den Ofen, weil die Größe der Tabelle dadurch zu stark aufgebläht wird, so daß die Suche nicht mehr so schnell abläuft?
für das suchen ist generell ein index von vorteil.
da die suche mittels halbschrittverfahren erfolgt, ist eine sortierte liste notwendig.
ohne eine sortierte liste muß sequentiell gesucht werden. das ist natürlich inperformanter.die datenspalte der tabelle wird vom dbms nicht sortiert. aber der index.
daher ist ein index besser.