Different styles for assigning a primary key in oracle sql - sql

Question

I was testing the following examples (1, 2 and 3) in APEX-Oracle SQL commands and all three examples seems to work fine, however, I thought the PRIMARY KEY is named/reserved keyword in oracle, so the question is there any difference between the primary keys in these three examples.
Please note that example_2 the primary key is in small letters
CREATE TABLE example_1(
ID int PRIMARY KEY,
LastName VARCHAR2(255) NOT NULL,
FirstName VARCHAR2(255),
Age int
);
CREATE TABLE example_2(
ID int primary key,
LastName VARCHAR2(255) NOT NULL,
FirstName VARCHAR2(255),
Age int
);
CREATE TABLE example_3(
ID int ,
LastName VARCHAR2(255) NOT NULL,
FirstName VARCHAR2(255),
Age int,
CONSTRAINT PK_example_3 PRIMARY KEY (ID)
);

Answer 1

No difference in functionality. Only difference is that for table example_3 the primary key is a named constraint and not a generated name.
"PRIMARY KEY" is not a reserved word (full list here) and case doesn't matter in the CREATE TABLE clause (object names can be case sensitive if enclosed in quotes)
You can easily check this yourself... query data dictionary USER_TABLES for details about the tables and USER_CONSTRAINTS to see if there are differences in the primary key constraints.

Answer 2

In Oracle INT is synonym for NUMBER(38) and that's bigger than a quad-precision integer. That's a big number that may be overkill for your app. I would recommend you use a smaller precision, like NUMBER(18) (a long) or so.
The first and second examples are equivalent. In the third case, you are assigning an explicit name (PK_EXAMPLE_3) to the primary key constraint. In the first two cases, the PK will end up with auto-generated "ugly" names. Not a big deal, but that name may be end up being different in different environments (dev, test, staging, prod) and that can be significant sometimes, when you submit SQL scripts to be executed by third parties, or in automated ways.
Other than that, your examples are almost equivalent.

Answer 3

As you noticed, letter case - in Oracle - doesn't matter. CREATE works as well as create or CrEAte. The same goes for primary key.
Letter case, though, would matter if you make a wrong step and decide to enclose names into double quotes; then you have to do that every time you reference that something (table, procedure, column, whatever), matching letter case exactly (but that's another issue we aren't discussing now).
You created table as
SQL> CREATE TABLE example_1(
2 ID int PRIMARY KEY,
3 LastName VARCHAR2(255) NOT NULL,
4 FirstName VARCHAR2(255),
5 Age int
6 );
Table created.
If you describe it, you'll notice that Oracle - by default - stores everything (into data dictionary) - in UPPER CASE and lets you reference it using any case you want:
SQL> desc example_1
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NOT NULL NUMBER(38)
LASTNAME NOT NULL VARCHAR2(255)
FIRSTNAME VARCHAR2(255)
AGE NUMBER(38)
SQL> select table_name from user_tables where table_name = 'EXAMPLE_1';
TABLE_NAME
--------------------
EXAMPLE_1
SQL> select id, LASTname, FirSTnaMe from exampLE_3;
no rows selected
SQL>
As you can see, your nicely written LastName became LASTNAME. As I said: you could have preserved it if you put it as "LastName" varchar2(255), but that's - in most cases - wrong and brings nothing but problems. Don't do that. Use e.g. last_name instead to improve readability.
As of constraints: as you didn't name them, Oracle set names automatically. These generic names aren't useful at all because you have no idea what they represent, simply by looking at their names:
SQL> select table_name, constraint_name, constraint_type
2 from user_constraints
3 where table_name = 'EXAMPLE_1';
TABLE_NAME CONSTRAINT_NAME CONSTRAINT_TYPE
-------------------- -------------------- --------------------
EXAMPLE_1 SYS_C009359 C
EXAMPLE_1 SYS_C009360 P
Yes, constraint type helps, but - why wouldn't you rather do as you did in your 3rd example and explicitly name the constraint?
SQL> select table_name, constraint_name, constraint_type
2 from user_constraints
3 where table_name = 'EXAMPLE_3';
TABLE_NAME CONSTRAINT_NAME CONSTRAINT_TYPE
-------------------- -------------------- --------------------
EXAMPLE_3 SYS_C009361 C
EXAMPLE_3 PK_EXAMPLE_3 P --> isn't this better?
SQL>
OK; you found two ways of creating (primary key) constraints:
one is inline (regardless of whether you give it a name or not):
id int primary key
another is out-of-line:
CONSTRAINT PK_example_3 PRIMARY KEY (ID)
the 3rd way is to use alter table statement:
SQL> CREATE TABLE example_2(
2 ID int,
3 LastName VARCHAR2(255) NOT NULL,
4 FirstName VARCHAR2(255),
5 Age int
6 );
Table created.
SQL> alter table example_2 add constraint pk_example_2 primary key (id);
Table altered.
I suggest you read carefully everything answerers said so far; you might find it useful.