Best datatype definition for sequence generated PK

Question

Hi everyone,
I realize the actual answer to this question will most likely be "it doesn't really matter," but as a typical database developer, my over-analytical self just can't move past this unless I handle it the "best" way.
I have surrogate primary keys in my tables generated by sequences incremented by 1. So, I want to enforce the constraint on this column to not allow decimal values like 38.5, for instance...just integers. I don't necessarily care about the precision, since, as far as I'm aware, there are no negative impacts for defining a column as NUMBER(38) vs NUMBER(10).
So, I've come to find three ways in defining this datatype to accomplish this. All of them end up being defined as NUMBER(38), which is why I figured it doesn't really matter, but there are some slight differences.
1.  CREATE TABLE IMOVERTHINKING (MY_PK NUMBER(*,0));
2.  CREATE TABLE IMOVERTHINKING (MY_PK INTEGER);
3.  CREATE TABLE IMOVERTHINKING (MY_PK NUMBER(38));The first two essentially do exactly the same thing. In USER_TAB_COLUMNS, both of those will give me a PRECISION of NULL and SCALE of 0. The third one will give me a PRECISION of 38 and SCALE of 0.
So, does anyone have a suggestion for a "best practice?" Is it best to define a PRECISION like in #3? Or, what about scalability? Say, if Oracle changes the max PRECISION to 58 one day. Will the undefined PRECISION automatically reflect that? Will I have to redefine all columns that used the #3 approach?
Thanks for any advice in advance.
Mark

Answer 1

Yeah, I have them as just plain number currently, but was thinking I shouldn't allow decimals, so I need to specify 0 scale. I don't have any restrictions on precision. I was kindof wondering how come I seem to be the only one worried about this, because, like you say, even Oracle just uses plain number. People would probably say that, since it's senquence-generated, decimals should never be a problem... But, I have an IF statement in my trigger to override the sequence if a primary key value is supplied (for my development purposes when loading bulk data sometimes I want to use the same primary keys as in my test/prod environments). Also, people would probably say that, since it's a pk field, it is essentially a relationship identifier, and it shouldn't matter if it has decimals in it or not. True, but it still bothers me, lol.