Re: primary keys and dictionary overhead
From: David Fitzjarrell <oratune_at_yahoo.com>
Date: Thu, 20 Oct 2011 08:58:29 -0700 (PDT)
Message-ID: <1319126309.49117.YahooMailNeo_at_web65409.mail.ac4.yahoo.com>
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
Date: Thu, 20 Oct 2011 08:58:29 -0700 (PDT)
Message-ID: <1319126309.49117.YahooMailNeo_at_web65409.mail.ac4.yahoo.com>
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-lReceived on Thu Oct 20 2011 - 10:58:29 CDT