Re: naming conventions for constraints

From: Rene Nyffenegger <rene.nyffenegger_at_gmx.ch>
Date: 5 May 2003 22:09:42 GMT
Message-ID: <b96nf6$ffqak$1@ID-82536.news.dfncis.de>

> On Thu, 01 May 2003 08:23:58 -0700, Daniel Morgan

><damorgan_at_exxesolutions.com> wrote:

>

>>My feeling is about constraint names is that they should have meaning when you
>>get a message from an end-user, or from a record in an error log table, that says
>>that the constraint has been violated.

>
> I don't think it's best practice to pass constraint names to the user.
>
> Using abbreviations is a work-around for unreasonable constraints
> (cough) on the length of constraint names. I don't know what the SQL
> standard says about that; I do know that Mimer SQL allows 128
> characters in a constraint name.
>
> But I don't want the user to see either a short, cryptic, encoded
> constraint name /or/ a 128-character constraint name. I want the user
> to see something they can communicate easily and reliably to another
> human. IME, users communicate error numbers more easily and reliably
> than anything else. And, IME, users have less trouble with multiple
> four-digit numbers than with long numbers. (They communicate
> 1234-5678-9012 more easily and more reliably than 123456789012.)

Then again

  ORA-02291: integrity constraint (RENE.FK_CUSTOMER) violated - parent key not found

can be more easily transmitted and communicated as

  ORA-02291: integrity constraint (RENE.FK_1234_5678_9012) violated - parent key not found

and does not need to be mapped in order to be mapped to which table it refers.

> So, in practice, I use either a table or a text file to map error
> numbers to constraint names. Then I write a couple of programs to
> generate constraints and *.h files (or whatever I need) from the
> table.
 

Rene Nyffenegger

-- 
  Projektleitung und Entwicklung in Oracle/C++/C# Projekten
  http://www.adp-gmbh.ch/cv.html

Received on Mon May 05 2003 - 17:09:42 CDT