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@xxxxxx>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@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 > > > -- ============================================= TRUTH WINS AT LAST, DO NOT FORGET TO SMILE TODAY ============================================= -- //www.freelists.org/webpage/oracle-l