Gibt es einen Grund, VARCHAR-Größen zu verwenden, die auf einen Offset von 128/256/4096 Byte gerundet sind?

In Datenbankschemata stelle ich oft fest, dass die VARCHAR-Größen auf die Byte-Offsets 128/256 oder 4096 gerundet sind. Ich habe es auch schon früher gemacht, und die Idee dahinter war wahrscheinlich etwas mit Effizienz.

Gibt es heutzutage noch einen triftigen Grund dafür? Ich verwende heutzutage oft '50', '100' oder '200' als VARCHAR-Größen, da diese natürlicher sind und dem Benutzer normalerweise auch in Validierungsprüfungen angezeigt werden.

Die einzige vernünftige Erklärung, die mir einfällt, wäre: Wenn das DBMS die Werte einer Spalte nacheinander speichert und die Größen nicht auf eine Zweierpotenz gerundet werden, müssen einige Elemente möglicherweise auf der Festplatte in zwei Seiten "aufgeteilt" werden Laufwerk (z. B. die ersten 10 Bytes auf Seite n und die nächsten 40 Bytes auf Seite n + 1), was in einigen Fällen zu zwei Lesevorgängen von der Festplatte anstelle von einem führen kann.

Wahrscheinlicher ist bei @Jan Hudec, dass viele Programmierer "128" oder "256" als "nette runde Zahlen" betrachten, was sie zu einer natürlicheren Wahl macht als ungerade Zahlen wie 137, 19 oder 100.

Im Allgemeinen gibt es keinen Grund für diese Spaltenlängen. Es wird keine Leistungsverbesserung einer varchar (100) -Spalte gegenüber einer varchar (128) -Spalte geben.

Ich würde das von Ihnen verwendete Datenbanksystem jedoch noch einmal überprüfen, um weitere Erläuterungen zu Einschränkungen und anderen herstellerspezifischen Vorbehalten zu erhalten.

Im Folgenden finden Sie ein gutes Beispiel für eine Einschränkung des Datenbanksystems für SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

Die Gesamtlänge der Zeile ist wichtiger als die Länge der einzelnen Spalten.

Ich erinnere mich nicht, ob es ein DBMS oder ein Compiler war, aber ich erinnere mich (vor langer Zeit), wie ich gelernt habe, Potenzen von 2 für Array- und Spaltenlängen zu verwenden. Es gab eine Rechtfertigung dafür, dass es "schneller" war, da die Implementierung Bitverschiebung verwenden konnte. Ob das noch gilt, ist eine offene Frage. Hat jemand eine Idee, ob es noch gültig ist?

Übrigens habe ich die Spaltenbreiten auf die einheitliche Zahl b / c verschoben. Es ist seltsam, den Benutzern mitzuteilen, dass das Zeichenlimit 256 Zeichen beträgt.

Einige sehr alte Datenbanken haben Sie auf Spalten mit einer Breite von 256 Zeichen beschränkt.

Es spielt wahrscheinlich keine Rolle, da Sie nur dann eine gewisse Speichereffizienz sehen würden, wenn die Größe Ihrer gesamten Zeile eine Potenz von 2 wäre. Es ist möglich, dass das Festhalten an Potenzen von 2 die Wahrscheinlichkeit erhöht, dass Ihre Zeilengröße erreicht wird würde auf eine Zweierpotenz kommen (da die meisten nativen Datentypen in der Regel eine Zweierpotenz haben (abhängig von der Datenbank)), aber ich würde es nicht zu einer festen Regel machen.

Es ist möglicherweise sinnvoller, wenn Sie mit großen Spalten (4 KB oder mehr) arbeiten, da diese möglicherweise separat gespeichert werden können, und wenn Sie ihre Größe so anpassen, dass sie in einen Speicherblock passen (unabhängig davon, was Ihre Datenbank für die Speicherung auf der Festplatte verwendet) Du etwas.

Obwohl ich nicht mit allen DBMS-Systemen vertraut bin, ist die kleinste "physische" Speichereinheit in Oracle ein "Block", der standardmäßig 2 KB groß ist. Die Bemessung Ihrer Spalten in Zweierpotenzen ist Teil einer umfangreicheren Bemessung Ihrer Zeilen, damit sie ordnungsgemäß in Speicherblöcke passen. Wenn Sie Ihre Spalten so dimensionieren, dass eine Zeile ein Byte mehr als die Blockgröße erfordert, müssen zwei Blöcke zugewiesen werden, und Ihre Zeile würde sich auch über zwei Blöcke erstrecken. Dies würde das Lesen, Einfügen und Scannen zeitaufwendiger machen, als wenn Sie jede Zeile einem Block zuordnen könnten (und nur eine Zeile in jedem Block). Das ist zumindest der historische Grund dafür. Heutzutage betrachten die meisten Leute diese Praxis als Suboptimierung.