Re: primary keys and dictionary overhead

From: Subodh Deshpande <deshpande.subodh_at_gmail.com>
Date: Fri, 21 Oct 2011 12:20:26 +0530
Message-ID: <CAJsOtB7J2J2xqy8SPW7bdeA35Q-__n-8LZ6yz3UCaYFn4VRuaQ_at_mail.gmail.com>



hello,
I think any sensible person will agree to your second paragraph..

Quote
There is also the 'flip side' where the vendor code is like 'scripture' and can't be modified by the unwashed ('the DBA'). UnQuote

If some code is not functioning proprely, then it should be changed..but this kind of mentality is developed when there is lack of documentation and the courage to change the code if it is need to change at that time..If your users are facing errors and you still think it can not be changed..then whats the use of such application..actually we used to have a team to take the feedback from endusers about whether they are facing any errors in using the application, do they require any new feature..and or do they want any other areas that can be bring under this application..

About change in code,Actually everybody including an enduser is also entitiled to recommend the change he/she wants..finally the code is meant to run the application..so that the enduser can work and or apply in day today life..not to remain the idle code in the application. Ofcourse the enduser will always speak his/her language..that is why you have SPRs..we used to have meetings on SPRs and also used to communicate the concerned person..

Lack of proper understandng, poor logical thinking, lack of courage to change develops this particualr attitude... In India we say 'Baba Wakya Pramanam' means I am doing this cause my forefathers have told me to do so...is useless..in todays era like it was in ancient era too..

lets hope that following will happen..especially 'he who shall remain nameless'

Quote
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> UnQuote

If you are using any application interface then the fields acts as bind variables..no alternatives to this...and using a database just by SQL is not correct way..it will affect the databse affect itself because of the architecture itself..performance and sometimes availability also..and this is why a 'userfriendly' application is developed with proper practices of QA/QC..all the six-sigma, CMM-lelvels, ISO, ITIL-V3 are to maintain 'userfiendlyness' not to add the 'cherry on cake' of certain DBA, team member and or certain company;s profile :)

my two cents..:)

thanks..subodh

On 20 October 2011 21:28, David Fitzjarrell <oratune_at_yahoo.com> wrote:

> 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.
>
>
>

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


--
http://www.freelists.org/webpage/oracle-l
Received on Fri Oct 21 2011 - 01:50:26 CDT

Original text of this message