Re: RI - pros and cons

A Modest Proposal (ala Swift)
Since it is a complex matter to specify different data types in a table there should be just one data type. Additionally, often complex naming conventions (eg birthdate, firstname, etc.) can lead to a great deal of debate and wasted meeting time and conflict on column and table names. Therefore, the following database programming practices should be standard:

    1, All columns will be varchar2(4000). This simplifies having to deal with the variety of data types and sizes. Varchar2 is a variable length field and so only takes up as much space as the actual data occupies. All other data types can be represented as varchar2. Users don't really need more than 4000 bytes in a field so 4000 is fine.

    2. The names of the columns will be the numeric position in the table. So the first column will be 1, the second 2, etc until the maximum is 1000.

    3. All columns will not have any constraints, null or default conditions. The presence of not null conditions and constraints is just a limit on what can go in the column. This practice generates too many errors and makes it too difficult for users to add data to the system.

    4. All tables will be named based upon the order in which they are created. The first table will be 1, the second 2 etc.

    5. There will be only one user , sys and the password will be shortened from the default change_on_install to just sys. Much easier to remember, shorter, and no one will get an error because they don't have rights to do what they need to do. All users will just use the sys password. This cuts down on the calls to internal company support about lost or forgotten passwords.

    6. To maintain performance the database must be run in non-archivelog mode.

    7.Since it is too complex to use bind variables in applications only hard parsed SQL will be allowed.

    8. Since it is confusing to program transactions all sql statements will be followed by the commit command (except the commit command).

These "best practices" should significantly cut down on development time and save money.
Jim
"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message news:3c98f481.201021974_at_ausnews.austin.ibm.com...
> I feel stupid even posting this question but there's trouble brewing in
River
> City. I'm getting caught between my "partner" DBA (with whom I have many
> philosophical differences) and the developers.
>
> New application being developed. Four rather simple tables - header data,
> detail data, and a couple of reference/look-up tables. Developers want RI
and I
> agree. DBA says "RI is more trouble than its' worth. You should take
care of
> it in your application." I'm caught in the middle, stongly disagreeing
(that's
> putting it diplomaticly) with the other DBA but having to maintain a
working
> relationship. He makes the claim "all the other DBA's I read on MetaLink
say RI
> is too much trouble" but won't produce evidence.
>
> Anyone want to comment on the technical merits of RI vs. not. I've always
felt
> that the benefits of RI (and normalized tables) was so obvious as to not
even
> require any further justification. Do I need to be re-educated, or . . .
.
>
>
Received on Thu Mar 21 2002 - 00:22:03 CST