Re: primary keys and dictionary overhead
- From: Robert Freeman <robertgfreeman@xxxxxxxxx>
- To: "deshpande.subodh@xxxxxxxxx" <deshpande.subodh@xxxxxxxxx>, David Fitzjarrell <oratune@xxxxxxxxx>
- Date: Sun, 23 Oct 2011 12:43:38 -0700 (PDT)
Comments in brackets mine to add clarity...
>> If some [vendor supplied COTS type] code is not functioning properly, 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..
Seat of your pants computing, gotta love it.....
I would disagree with this statement for many reasons. There are some very good
and valid reasons not to go fudding around with vendor supplied code. These
include:
1. The potential to loose vendor support.
2. The potential to loose track of all of the changes you have made to a code
tree that is not your code tree.
3. The potential to accidentally rewrite the code/SQL in such a way that it's
functionality is no longer correct.
4. The problems involved with future upgrades of the vendor package because of
the changes that have been made.
5. The potential legal issues revolving around changing the vendor code (ie:
reverse engineering violating contractual agreements).
I would agree that if there are problems with vendor supplied code that those
problems need to be addressed. However from an Enterprise point of view (read
- NOT SEAT OF YOUR FRIGGIN PANTS) this needs to be dealt with by the vendor
and through the support channels that you have established with the vendor.
This isn't about courage. It's about running an Enterprise in a mature,
methodical and common sense kind of way.
If your response is that the vendor does not supply is with good support - then
who's fault is that really? Who picked out the vendor and didn't ask questions
about future support? Who didn't pay for support? Who is responsible for having
bought this package in the first place? All of the reasons to have the change
vendor supplied code, in the end, really boil down to some very bad decision
making at some point on the part of the people who actually bought that code.
There are unfortunate times when you have to bite the bullet and do what you
can. Perhaps the vendor is out of business or perhaps they no longer provide
support for the version you are on (or my favorite is that we have our own
internal application that we lost the code tree too). Regardless, the reasons
that you get in these positions are generally due to poor poor laxidasial
management of our Enterprise assets. The same attitude that would lead one to
*carelessly* change vendor code is the same attitude that makes it a
requirement to do so. In my opinion.
>> 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..
I think that our forefathers had some pretty damned good ideas that should not
be so lightly thrown out. I also think that they should also not be just
followed blindly without thinking. The real danger is that we don't respect the
benefit of our forefathers thinking while at the same time realizing that times
do, in fact, change and that their thinking was predicated on truths that may
no longer exist.
One thing I do see, a lot, is this gulf between what I see as the professional
IT types and the seat-of-their pants IT types. The professional IT person is
typically very cautious, most especially the older ones who came from the days
when computing power really cost something. The seat of the pants types have no
fear, because they don't stop to think. Development methodologies such as Agile
(which I love by the way) really encourage these types, and yet they only seem
to accept the parts of it that appeal to their ADHD personalities. They are
quick to dismiss the rigor and methodical beauty and *stability* that
traditional data processing techniques offer. Examples? I've seen plenty of
agile projects that have failed because the development team didn't want to be
bothered to gather requirements ahead of time to any real degree, or because
the momentum of the planned iterations was such that they could not see (or
would not see) the snowballing path of
death that they were creating for themselves. I kind of come from a mix of the
"old-school" and the "new-school", and as such I can see the benefits of each,
and the downsides of each approach. I tend to fall in the middle then.
I think that it's not fair to label those with a cautious approach as lacking
proper understanding, or question their ability to think logically or lack
courage. Typically the difference between those that you describe and those who
do not posses those qualities is experience or personality (or both).There is a
place for a seat-of-your-pants thinker and a place for the traditional take
your time and think about what your going to do traditionalist.... The best
managers, in my opinion, are in-between and can pretty quickly determine which
approach is the most appropriate.
>> and using a database just by SQL is not correct way
Wow... this is a very dangerous statement to make and I hope you can please
clarify your point-of-view here. Using SQL set processing in the database is so
often almost always the right choice that I have to believe that I'm not
understanding your point correctly here. I have seen case after case after case
where SQL set processing trumps anything procedural in terms of performance.
Just because we HAVE PL/SQL does not mean we need to be using PL/SQL. Just
because we have Java or C#, or whatever programming language does not mean that
the data processing needs, or should, happen at that layer.
I will grant that there are specific use cases where processing might need to
happen at a different layer (for example, true Big Data) than the relational
database itself. There are also clearly cases where specific types of
processing require different database architectures (ie: OLTP vs. Data
warehouses) but at the end of the day, you will get much better data processing
performance out of a database by doing that processing at the database layer
most of the time. There are always exceptions to every rule, of course.... but
they are exceptions, not general cases.
For me, what concerns me is the laid back approach I see with respect to data
processing. More and more I see developers who for various reasons want to go
play with relational alternatives (ie NoSQL and in memory kinds of databases)
for many reasons (lack of agility, licensing, lack of knowledge, etc). IMHO,
all this does is make the stack more complex in the end. The problem is that
the seat-of-your-pants folks don't seem to get that all the time.... they are
just working with a cool stack (never mind if it's buggy and bleading edge).
And that is where the voice of your forefathers rightly should be stepping in
and saying "Hold on there folks", making you step back and assess the decisions
being made.
My opinion... YMMV.....
Robert
Robert G. Freeman
Master Principal Consultant, Oracle Corporation, Oracle ACE
Author of various books on RMAN, New Features and this shorter signature line.
Blog: http://robertgfreeman.blogspot.com
Note: THIS EMAIL IS NOT AN OFFICIAL ORACLE SUPPORT COMMUNICATION. It is just
the opinion of one Oracle employee. I can be wrong, have been wrong in the past
and will be wrong in the future. If your problem is a critical production
problem, you should always contact Oracle support for assistance. Statements in
this email in no way represent Oracle Corporation or any subsidiaries and
reflect only the opinion of the author of this email.
________________________________
From: Subodh Deshpande <deshpande.subodh@xxxxxxxxx>
To: David Fitzjarrell <oratune@xxxxxxxxx>
Cc: Andy Klock <andyklock@xxxxxxxxx>; "oracledbaquestions@xxxxxxxxx"
<oracledbaquestions@xxxxxxxxx>; "niall.litchfield@xxxxxxxxx"
<niall.litchfield@xxxxxxxxx>; "Hemant.Chitale@xxxxxx" <Hemant.Chitale@xxxxxx>;
"oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>; Luba Marshalkina
<witneyl@xxxxxxxxx>
Sent: Thursday, October 20, 2011 11:50 PM
Subject: 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
=============================================
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
