Bei NUMBER-Spalten in Oracle hilft die Angabe einer Länge bei der Leistung?

7

Gibt es einen echten Leistungsunterschied zwischen NUMMER, NUMMER (3) und NUMMER (10)? Verwendet das RDBMS nicht 32 Bits, um den Wert unabhängig zu speichern, und beschränken Sie einfach die Länge der Daten, wenn Sie als Zeichenfolge betrachtet werden?

Ein Kollege hat darüber diskutiert, dass es z. B. effizienter ist, NUMBER (10) als NUMMER / NUMMER (11) zu verwenden, da n die Anzahl der Bytes und nicht die Länge des Bytes ist Daten in Zeichen. Normalerweise würde ich zustimmen, die Spaltengröße zu begrenzen, wenn die Anzahl der Zeilen garantiert 10 ^ n oder so nicht überschreiten würde, aber für diese spezielle Datenbank war die Grenze für die Anzahl der Zeilen buchstäblich "so viele wie möglich", z. 2 ^ 32 oder ~ 4 Milliarden, obwohl wir diesen Betrag nie erreichen würden. Ein "niedrigstes Maximum" für diese Situation zu finden, erscheint sinnlos und Zeitverschwendung, und ich dachte, die Verwendung von NUMBER ohne Angabe einer Länge wäre einfacher und würde keine Strafen nach sich ziehen. Habe ich Recht?

    
Jake Petroules 15.11.2010, 23:17
quelle

3 Antworten

11

Technisch definieren Sie keine Länge, sondern eine Genauigkeit und Skalierung.

Der gleiche numerische Wert (z. B. 100, 4.3) nimmt den gleichen internen Wert an, unabhängig von der Genauigkeit und der Skalierung, die die Spalte definieren.

Der maximale Wert, den eine Spalte halten kann, wird durch BEIDE Präzision und Skalierung bestimmt. Das heißt, Sie können den Wert 100 in einer Spalte von NUMMER (3,0) speichern, aber nicht in einer Spalte von NUMMER (3,1).

Wenn eine Spalte keine Dezimalzahl speichern soll, sollte die Skala im Allgemeinen Null sein. Denken Sie daran, dass, wenn Sie versuchen, 10.12 in einer NUMMER (3,0) zu speichern, wird der Wert 10 gespeichert. Es ist kein Fehler (denn wenn es so wäre, würde es Ihnen schwer fallen, den Wert von einem Drittel zu speichern etwas). Wenn Sie einen Fehler haben möchten, sollten Sie eine höhere Skalierung zulassen und eine Einschränkung verwenden, um zu verhindern, dass sie jemals verwendet wird.

Ich glaube auch, dass Sie versuchen sollten, eine "vernünftige" Präzision zu verwenden. Wenn Sie tausend Werte in jeder Sekunde für eintausend Jahre speichern würden, würden Sie immer noch innerhalb von 14 Ziffern passen. Wenn ich eine Spalte mit NUMMER (14,0) sehe, weiß ich, dass auf meinem Bildschirm oder Ausdruck 14 numerische Zeichen angezeigt werden sollen. Wenn ich nur NUMMER oder NUMMER (38,0) sehe, habe ich wirklich keine Anleitung erhalten und kann 14 Zeichen erraten. Und wenn sie anfangen 16-stellige Kreditkartennummern einzugeben, dann liege ich falsch. Deshalb möchte ich nicht raten.

Auch in PL / SQL haben sie einen PLS_INTEGER-Datentyp, der bis zu 2147483647 reicht. Wenn ich eine Spalte von NUMBER (9,0) sehe, weiß ich, dass ich sie in einen PLS_INTEGER einfügen kann. Es gibt wahrscheinlich ähnliche Überlegungen für Java oder .Net usw., wenn sie herausfinden wollen, welchen Datentyp, welche Skalierung und welche Genauigkeit beim Ziehen / Drücken von Daten in die Datenbank zu verwenden ist.

    
Gary Myers 16.11.2010, 03:24
quelle
8

Es macht keinen Unterschied, ob Sie NUMBER(1) oder NUMBER(10) verwenden. Die Speicheranforderungen sind gleich und hängen von den Daten ab, die Sie darin speichern.

Der einzige mögliche Unterschied in der Leistung liegt zwischen NUMBER() und NUMBER(N) , da letztere beim Speichern die Größe überprüfen müssen. Aber das ist so vernachlässigbar, dass es wahrscheinlich nicht einmal messbar ist.

    
Wolph 15.11.2010 23:24
quelle
4

Bezüglich der 32 Bits - nein. In Oracle ist der NUMBER-Typ ein Gleitkommawert mit variabler Länge der Basis 10 mit einer garantierten Genauigkeit von 38 Stellen. Siehe die Oracle-Dokumentation und diese AskTom-Frage .

& lt; Soapbox & gt;

Tatsächlich denke ich, dass NUMBER tatsächlich eines von The Best Things in Oracle ist. Ich habe eine Binsenweisheit mit dem Effekt gelesen, dass "jedes Produkt (Sprache, Datenbank usw.), das Entwickler benötigt, um die Anzahl der Bits in einer numerischen Variablen zu kennen und sich darum zu kümmern, für die geschäftliche Programmierung ungeeignet ist" und damit völlig einverstanden ist. Es gibt keinen Grund dafür, dass jemand Buchhaltungssoftware schreibt, um anzugeben, ob ihr Wert in eine skalierte 32-Bit-Dezimalzahl passt oder ob ANSI-Gleitkommazahlen doppelter Länge ein Problem verursachen könnten (sie werden ), oder eine Unzahl anderer Themen, die sich mit dem Thema Zahlen in Computern beschäftigen. Zahlen sind zu wichtig, um zu effizient zu sein. YMMV.

& lt; / soapbox & gt;

Teilen und genießen.

    
Bob Jarvis 16.11.2010 12:42
quelle

Tags und Links