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