Re: primary keys and dictionary overhead
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:
- The potential to loose vendor support.
- The potential to loose track of all of the changes you have made to a code tree that is not your code tree.
- The potential to accidentally rewrite the code/SQL in such a way that it's functionality is no longer correct.
- The problems involved with future upgrades of the vendor package because of the changes that have been made.
- 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 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_at_gmail.com> To: David Fitzjarrell <oratune_at_yahoo.com> Cc: Andy Klock <andyklock_at_gmail.com>; "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>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>; Luba Marshalkina <witneyl_at_yahoo.com> Sent: Thursday, October 20, 2011 11:50 PM Subject: Re: primary keys and dictionary overhead
I think any sensible person will agree to your second paragraph..
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'
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..:)
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
> 22.214.171.124) 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 -- http://www.freelists.org/webpage/oracle-lReceived on Sun Oct 23 2011 - 14:43:38 CDT