Re: RI - pros and cons

"Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message news:f_em8.82030$ZR2.36910_at_rwcrnsc52.ops.asp.att.net...
> 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 . .
.

Ah, the Peoplesoft philosophy...

Paul Received on Thu Mar 21 2002 - 14:26:48 CST