Re: primary keys and dictionary overhead
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: Hemant.Chitale@xxxxxx
- Date: Thu, 20 Oct 2011 09:47:15 +0100
Oracle 7 was also the first release with declarative referential integrity.
So up until that point not only were string literals the standard way to
program against databases, ensuring data integrity was a job for the
database programmer in code rather than in database. Then you have the
education cycle, the adoption cycle and the release cycle. It seems to me
that any commercial product released before about 1995/1996 that used
declarative referential integrity and bind variables would have been way
ahead of its time - and almost certainly hit bugs with the new features.
On Thu, Oct 20, 2011 at 2:59 AM, Chitale, Hemant Krishnarao <
Hemant.Chitale@xxxxxx> wrote in response to David:
> > Apparently a few vendors did that 20+ years ago and claimed it was for
> performance reasons. Never mind that their code was suspiciously absent of
> bind variables forcing a hard parse for every run of a query where only the
> string literal value was changed.
>
>
> Oracle V7 was released around 1991 or so. That was the first time a
> "Shared Pool" was introduced. Awareness of Binds was still sometime in the
> future.
>
>
> Hemant K Chitale
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of David Fitzjarrell
> Sent: Thursday, October 20, 2011 4:53 AM
> To: mark.powell2@xxxxxx; ORACLE-L
> Subject: Re: primary keys and dictionary overhead
>
> Apparently a few vendors did that 20+ years ago and claimed it was for
> performance reasons. Never mind that their code was suspiciously absent of
> bind variables forcing a hard parse for every run of a query where only the
> string literal value was changed. Never mind that their idea of referential
> integrity was 'enforced' in the application code and not the database.
> Never mind that they also enforced uniqueness in the same way. Which
> explains why migrating from one of these types of applications to one which
> uses database constraints requires far more data cleanup than should be
> necessary.
>
> It's funny sometimes what vendors do in the name of 'performance'.
> David Fitzjarrell
>
>
>
> This email and any attachments are confidential and may also be privileged.
> If you are not the addressee, do not disclose, copy, circulate or in any
> other way use or rely on the information contained in this email or any
> attachments. If received in error, notify the sender immediately and delete
> this email and any attachments from your system. Emails cannot be
> guaranteed to be secure or error free as the message and any attachments
> could be intercepted, corrupted, lost, delayed, incomplete or amended.
> Standard Chartered PLC and its subsidiaries do not accept liability for
> damage caused by this email or any attachments and may monitor email
> traffic.
>
> Standard Chartered PLC is incorporated in England with limited liability
> under company number 966425 and has its registered office at 1 Aldermanbury
> Square, London, EC2V 7SB.
>
> Standard Chartered Bank ("SCB") is incorporated in England with limited
> liability by Royal Charter 1853, under reference ZC18. The Principal Office
> of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In
> the United Kingdom, SCB is authorised and regulated by the Financial
> Services Authority under FSA register number 114276.
>
> If you are receiving this email from SCB outside the UK, please click
> http://www.standardchartered.com/global/email_disclaimer.html to refer to
> the information on other jurisdictions.
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
//www.freelists.org/webpage/oracle-l
Other related posts:
