RE: primary keys and dictionary overhead

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 Subodh Deshpande Sent: Thursday, October 20, 2011 4:10 AM To: oracle-l-freelists
Subject: Re: primary keys and dictionary overhead

20+ years ago it was mostly Oracle 5 with SQL forms 2.0, reports 2.0, sql calc, Pro*c and if I remember correctly then at that time there were no constraints such as unique, primary etc on tables.forget refereal integrity constraints..
But indexes were very much there..I do not remember where I used/seen any unique indexs on tables..not null columns were allowed.. and yes it is absolutely right...all the business logic was enforced using application code.

Oracle 7 was introduced (rather I remember that I used) some where after 1996.

We should be thankful to the fact that atleast some sort of RDBMS was present 20 years ago..
cause in 1989 when I learned cobol we were writing to files...not to tables....
GWBASIC was a toy,,DBASE III+, fox*pro, clipper were known to us..

At that time I first came across a well structured salary computation program using shell programming in Unix environment.. all the logic of day-today business entry, DSS, MIS was applied using shell programming in UNIX..

During the same time I was fallen in love with DBASEIII+, clipper etc..more and when I seen Oracle 5 and 'AMRUT' (Advanced Manufacturing Resource Utilisation) ERP application, I realised how foolish I was...

And all the applications of AMRUT were performing very well...during the Y2K we migrated most of the application to Oracle 7 and D2K without more trouble...we faced the probems in Pro*c, SQL*Reports..

Today, if migration of such applications is necessary then understand the business logic and built new application..

thanks..subodh

On 20 October 2011 07:29, Chitale, Hemant Krishnarao <Hemant.Chitale_at_sc.com>wrote:

> > 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of David Fitzjarrell
> Sent: Thursday, October 20, 2011 4:53 AM
> To: mark.powell2_at_hp.com; 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.
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
=============================================
TRUTH WINS AT LAST, DO NOT FORGET TO SMILE TODAY
=============================================


--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l