== Why is this an issue?

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)

=== Message

Use the "PLS_INTEGER" type here; it's more performant.


=== Highlighting

``++NUMBER(1-9)++``


endif::env-github,rspecator-view[]