Please Help - Avoid default name when creating constraints

Question

Here I am creating two very simple tables:
create table supplier
     id number not null,
     constraint pk_supplier primary key (id)
create table product
id number not null,
supplier_id number not null,
constraint pk_product primary key (id),
constraint fk_product_supplier_id
foreign key (supplier_id) references supplier(id)
After done while I choose to view table constraint information by using:
select table_name, constraint_name
from user_cons_columns
where lower(table_name) = 'product';
I get result:
TABLE_NAME                     CONSTRAINT_NAME
PRODUCT                        SYS_C005441
PRODUCT                        SYS_C005442
PRODUCT                        PK_PRODUCT
PRODUCT                        FK_PRODUCT_SUPPLIER_ID
What is the "SYS_C005441" and "SYS_C005442" for? Can I avoid creating them?
Thanks

Answer 1

Justin Cave wrote:
Are you suggest not explicitly naming all your constraints? Or just the NOT NULL ones?No, not at all. Did not even thought that far when I responded. Bit of foot in mouth as I only thought of not null constraints. Blame it on a lack of coffee. :-)
I usually name primary & foreign key and check constraints. But not null constraints - too much of an effort to name them IMO.
But you do raise an interesting topic. Why bother naming some constraints (e.g. PK and FK) and not others (e.g. not null)? So playing devil's advocate, why should we be naming constraints at all?
It sounds like you're suggesting that all constraints should get system default names. Well, one can argue that the same effort of naming other constraints is not worth it - why have null constraints as the exception to implicit naming? I would think that the issue I raised also applies to all constraints.
You have multiple foreign key constraints for INVOICE_ID - how do you name these? I would like both the table and column names as this will provide the meaning needed when seeing the constraint being violated. But with 30 chars only, that is a problem. So invariable one needs to start to abbreviate table and column names in order to make it meaningful constraint name. Been there many times - disliked the constraint name I came up with every time, as it was a compromise and not the actual naming format I would have preferred.
If that's what you're suggesting, doesn't that create problems for you when different environments have different constraint names? I know personally that I'd much rather have named constraints so that when there are constraint violation errors in production, I can start troubleshooting the problem in my local environment without first determining how to map the production constraint name to my local database's constraint name. Understand your point - and yes, it can be an issue. But by the same token, why should an application user ever see a default Oracle exception? With the exception of system-type exceptions (e.g. no more tablespace space, eof on communcation channel), all other exceptions should be custom application exceptions.
Showing for example a "+ORA-00001: unique constraint (xxx.xxxxx) violated+" is wrong IMO. The app code should trap that exception and raise a meaningful and unique application exception for that. The user seeing anything other than a custom app exception, should itself be an exception.
And I'd much rather be able to put the constraint name in a script that is to be promoted through the environments rather than coming up with a process that uses dynamic SQL to figure out the name of the constraint I want to do something to. Well, I would not rely on a constraint name itself to determine what it is. Just because it says fk_invoiceid_invoices does not mean that is is a foreign key on column invoice_id and references the invoices table. The safe/proper thing to do would be to query the data dictionary and confirm just what that constraint is.
I suppose if you know that all the lower environments are very recent clones of production rather than running all the scripts in source control that these problems may not be particularly large. But I'm curious if you have some better approach to handling them (or if I'm completely misinterpreting what you're suggesting).Not sure if you recall some feature discussion with Tom and others (was on asktom?) when someone came up with this core issue and suggested it be addressed by allowing one to define an exception message with the definition of the constraint. Cannot recall the exact syntax proposed, but I do remember thinking that it was not a shabby idea - as this solves the problem of having to invent a meaningful name using 30 chars only. And it also removes the need for trapping that constraint violation in all app code that may cause the exception and raising a custom and meaningful app exception instead. Not too mention that plain and direct SQL access will show the same exception message.
Perhaps in Oracle 12c? I assume the c as it seems that The Next Big Thing is cloud computing and surely Oracle 12 will somehow try to exploit that buzzword - as it has with i (Internet) and g (Grid) versions. ;-)