> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. **"Bit ist Bit" mag in der allgemeinen Theorie gelten.** Aber in der vorliegenden Praxis ist "Byte" ist nicht gleich "Byte" und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei (hier angezeigten, aber immer noch nicht sachgemäßen) Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen (allein die Kollation zu beachten zieht sehr viele, eigentlich unnötige Operationen nach sich) - ergo der erforderlichen Rechenzeit. Fazit: Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nicht nur mehr lesen bzw. schreiben als unbedingt erforderlich ist und muss auch eigentlich unnötige Operationen (darunter für den optimalen Datentyp nicht angezeigte oder sogar unmögliche!) ausführen. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.

> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. **"Bit ist Bit" mag in der allgemeinen Theorie gelten.** Aber in der vorliegenden Praxis ist "Byte" ist nicht gleich "Byte" und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen (allein die Kollation zu beachten zieht sehr viele, eigentlich unnötige Operationen nach sich) - ergo der erforderlichen Rechenzeit. Fazit: Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nicht nur mehr lesen bzw. schreiben als unbedingt erforderlich ist und muss auch eigentlich unnötige Operationen (darunter für den optimalen Datentyp nicht angezeigte oder sogar unmögliche!) ausführen. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.

> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. **"Bit ist Bit" mag in der allgemeinen Theorie gelten.** Aber in der vorliegenden Praxis ist "Byte" ist nicht gleich "Byte" und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen (allein die Kollation zu beachten zieht sehr viele, eigentlich unnötige Operationen nach sich) - ergo der erforderlichen Rechenzeit. Fazit: Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nicht nur mehr lesen bzw. schreiben als unbedingt erforderlich ist und muss auch eigentlich unnötige Operationen ausführen. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.

> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. **"Bit ist Bit" mag in der allgemeinen Theorie gelten.** Aber in der vorliegenden Praxis ist "Byte" ist nicht gleich "Byte" und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen (allein die Kollation zu beachten zieht sehr viele, eigentlich unnötige Operationen nach sich) - ergo der erforderlichen Rechenzeit. Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nämlich mehr lesen bzw. schreiben als unbedingt erforderlich ist. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.

> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. **"Bit ist Bit" mag in der allgemeinen Theorie gelten.** Aber in der vorliegenden Praxis ist "Byte" ist nicht gleich "Byte" und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen - ergo der erforderlichen Rechenzeit. Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nämlich mehr lesen bzw. schreiben als unbedingt erforderlich ist. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.

> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. "Bit ist Bit" mag in der allgemeinen Theorie gelten. Aber in der vorliegenden Praxis ist Byte ist nicht gleich Byte und ergo "Bit eben nicht gleich Bit". Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen - ergo der erforderlichen Rechenzeit. Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nämlich mehr lesen bzw. schreiben als unbedingt erforderlich ist. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.

> Solange der Spaltentyp ordinal ist und keiner zusätzlchen Translation bedarf, macht das für die DBM keinerlei Unterschied. Bit ist Bit. "Bit ist Bit" mag in der allgemeinen Theorie gelten. Aber in der vorliegenden Praxis ist Byte ist nicht gleich Byte. Das gilt vor allem, wenn es sich bei den als Strings erfassten "UID" tatsächlich um hexadezimale Zahlen handelt. (Das wurde unwidersprochen stehen gelassen). Dann wird nämlich Speicherplatz verschwendet - was bedeutet, dass mehr gelesen (und ggf. neu geschrieben) werden muss. Offensichtlich wird dieses wenn man sich den faktischen Wertebereich ansieht: * 1 Byte in ganzen Zahlen bedeutet, 2^8, also 256 Varianten. * 1 Byte als String mit den Varianten [0-9a-f] sind 16 Varianten. Die Speicherdichte liegt also bei ganzzahligen Werten um das 16-fache höher als bei einem String bei dem der größte Teil des Wertebereiches ungenutzt bleibt. Selbst wenn man davon ausgeht, dass in der "UID" keine hexadezimalen, sondern ganz normale Zeichen sind, so darf man doch daran glauben, dass die "UID" tatsächlich nicht alle selbst für [ASCII](https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) gültigen Zeichen beinhalten soll. Dieses schon weil darunter etliche Steuerzeichen sind. Also kommt es durch die Nichtnutzung des Wertebereichs zu einer Nichtnutzung der möglichen Speicherdichte, mithin Speicherverschwendung. Dies gilt selbst bei Optimierung wie feststehende Länge des Strings. Im schlimmsten Fall haben wir es noch mit Strings variabler Länge, einem FULLTEXT-Index und womöglich UTF-8 zu tun, denn dann steigt nicht nur der Anteil verschwendeten aber zu bearbeitenden Bits sondern auch die Zahl und Komplexität der Operationen - ergo der erforderlichen Rechenzeit. Wird jetzt der Speicherplatz nicht optimal genutzt, dann muss die Software nämlich mehr lesen bzw. schreiben als unbedingt erforderlich ist. Und fest steht, dass es niemals schneller geht, mehr zu tun als eigentlich erforderlich ist, als nur das Erforderliche zu tun. **Aber wie schon dargestellt:** Die im Thread gegenständliche, starke Verzögerung ist hierdurch (einzeln betrachtet, siehe nächster Absatz) nicht erklärt. Das nicht optimale Format mag zur Verzögerung beitragen, dies aber im Hinblick auf die Anzahl der Datensätze und der Leistungsfähigkeit heutiger Rechner nur in einem geringem, tatsächlich von Menschen nicht mehr spürbaren Ausmaß. Freilich muss andererseits beachtet werden, dass es bei hoher Auslastung mit einer Vielzahl von "parallelen" Abfragen auf derlei verschwenderisch angelegte Datentabellen dann doch zu spürbaren Antwortverzögerungen kommen kann. Im Hinblick darauf sollte stets das optimale Format für die Speicherung gewählt werden.