47 lines
1.3 KiB
Plaintext
47 lines
1.3 KiB
Plaintext
Using a ``++NUMBER++`` to store an integer is less performant than using a ``++PLS_INTEGER++``. ``++PLS_INTEGER++``s require less storage than ``++NUMBER++``s, and benefit from the use of hardware math, as opposed to the library math required for ``++NUMBER++``s. Even more performant is the ``++SIMPLE_INTEGER++`` subtype of ``++PLS_INTEGER++``. However, changing to either of these types is only appropriate under certain circumstances.
|
|
|
|
|
|
``++PLS_INTEGER++`` is only a candidate for ``++NUMBER++`` with a scale of up to 9.
|
|
|
|
``++SIMPLE_INTEGER++`` has the same size limitation, in addition to it's ``++NOT NULL++`` constraint and lack of overflow checking.
|
|
|
|
|
|
This rule raises an issue when a ``++NUMBER++`` is declared with a scale of 9 or less.
|
|
|
|
|
|
== Noncompliant Code Example
|
|
|
|
[source,sql]
|
|
----
|
|
DECLARE
|
|
son NUMBER(1); -- Noncompliant
|
|
rumbo NUMBER(9); -- Noncompliant
|
|
conga Number(10); -- Ignored; falls outside the PLS_INTEGER range
|
|
compalsa PLS_INTEGER;
|
|
----
|
|
|
|
|
|
== Compliant Solution
|
|
|
|
[source,sql]
|
|
----
|
|
DECLARE
|
|
son SIMPLE_INTEGER;
|
|
rumbo PLS_INTEGER;
|
|
conga Number(10); -- Ignored; falls outside the PLS_INTEGER range
|
|
compalsa PLS_INTEGER;
|
|
----
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
include::message.adoc[]
|
|
|
|
include::highlighting.adoc[]
|
|
|
|
endif::env-github,rspecator-view[]
|