RE: primary keys and dictionary overhead
Date: Thu, 20 Oct 2011 13:18:24 -0400
Message-ID: <C95D75DD2E01DD4D81124D104D317ACA17B616AA67_at_JAXMSG01.crowley.com>
I know two... say financial apps that do not use foreign key constraints.... (oh you might find one or two). and the reason I am told this is so, is that the same app and tables can work in multiple DBMS's.
Hmmm.... I'm with Tom Kyte in that I'll analogize from his expert oracle book. Their 'different', so code for it.
But apparently, it is not necessary to take advantage of the individual strengths and differences in a DBMS as it is working for these vendors to have one basic set of code, and not individual sets.
So the point is that -- well, some of these guys have their reasons. Of course we all have our reasons for agreeing or disagreeing, the original architects are probably not even available anymore.
Joel Patterson
Database Administrator
904 727-2546
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of David Fitzjarrell
Sent: Thursday, October 20, 2011 11:58 AM
To: Andy Klock; deshpande.subodh_at_gmail.com
Cc: oracledbaquestions_at_gmail.com; niall.litchfield_at_gmail.com; Hemant.Chitale_at_sc.com; oracle-l_at_freelists.org; Luba Marshalkina
Subject: Re: primary keys and dictionary overhead
I don't disagree; I started my career with Oracle 6.0.24 where primary keys and unique indexes were available,as well as hot backups (yes, it was 'bleeding edge' technology then). That was 1989, and Oracle 7 was about to be unleashed. I've worked with every release since then (currently on 11.2.0.2) and have been fortunate to have worked on some major projects for major companies in the span of my career. Having been on both sides of the application fence (development and support) I've been familiar with what various releases of Oracle had available in terms of constraints, indexing, etc. which is why it surprises me (actually galls me but, hey, I want to be nice) that vendors can STILL write crappy (yes, you read that correctly) code that 'enforces' uniqueness and referential integrity outside of the database engine and fails to utilize bind variables, even for 'singleton' inserts. I could name at least one vendor that still does this today (but
I won't). It doesn't matter how many inserts you perform with a given statement, if it will be run repeatedly it should be using bind variables. Granted with Oracle 6 and Forms 2..3 this wasn't possible but there is no reason in this day and age to continue to write applications as if they are using the first release of Access when they are pointed to a fairly current release of Oracle. My complaint was not directed at the releases of Oracle prior to Oracle 7, it is directed at current vendors who won't enter the modern age by continuing to write antiquated code so out of touch with reality that even Mr. Peabody and his boy Sherman would need a trip in the WAYBAC machine to view the source.
Don't take my 'rant' the wrong way -- I've worked along side vendors more than willing to take advice from the field in order to improve their product and increase their understanding of the database. There is also the 'flip side' where the vendor code is like 'scripture' and can't be modified by the unwashed ('the DBA'). I suppose we'll be dealing with this ad infinitum/ad nauseam. And application code isn't the only victim in this; we've been fighting a battle with 'false facts' about Oracle for years and it seems as though the battle is slowly being won as the influence of 'he who shall remain nameless' is diminishing; let's hope this trend finds its way into the application realm so that some day the sun will shine, the birds will sing, water will be pure, bind variables will be abundant and queries will never need tuning. <play "Happy Working Song" here>
My two and one-half cents. You can keep the change.
David Fitzjarrell
From: Andy Klock <andyklock_at_gmail.com> To: "deshpande.subodh_at_gmail.com" <deshpande.subodh_at_gmail.com> Cc: "oracledbaquestions_at_gmail.com" <oracledbaquestions_at_gmail.com>; "niall.litchfield_at_gmail.com" <niall.litchfield_at_gmail.com>; "Hemant.Chitale_at_sc.com" <Hemant.Chitale_at_sc.com>; "oratune_at_yahoo.com" <oratune_at_yahoo.com>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org> Sent: Thursday, October 20, 2011 5:30 AM Subject: Re: primary keys and dictionary overhead
Please don't take this the wrong way, but you are all old.
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Oct 20 2011 - 12:18:24 CDT