Re: primary keys and dictionary overhead

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@xxxxxxxxx> 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@xxxxxxxxx>
> *To:* "deshpande.subodh@xxxxxxxxx" <deshpande.subodh@xxxxxxxxx>
> *Cc:* "oracledbaquestions@xxxxxxxxx" <oracledbaquestions@xxxxxxxxx>; "
> niall.litchfield@xxxxxxxxx" <niall.litchfield@xxxxxxxxx>; "
> Hemant.Chitale@xxxxxx" <Hemant.Chitale@xxxxxx>; "oratune@xxxxxxxxx" <
> oratune@xxxxxxxxx>; "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
> *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


Other related posts: