re : Mentality / Seat of The Pants : was RE: primary keys and dictionary overhead

1. Convert this to a Blog Post
2. Write this up as an Article worth publishing in a few journals

I agree with

"I think that our forefathers had some pretty damned good ideas that should not be so lightly thrown out"

"The professional IT person is typically very cautious"

"Using SQL set processing in the database is so often almost always the right choice"

"...what concerns me is the laid back approach I see with respect to data processing."

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

Hemant K Chitale  

From: Robert Freeman [mailto:robertgfreeman_at_yahoo.com] Sent: Monday, October 24, 2011 3:44 AM
To: deshpande.subodh_at_gmail.com; David Fitzjarrell Cc: Andy Klock; oracledbaquestions_at_gmail.com; niall.litchfield_at_gmail.com; Chitale, Hemant Krishnarao; oracle-l_at_freelists.org; Luba Marshalkina Subject: Re: primary keys and dictionary overhead  

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.

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.

--
http://www.freelists.org/webpage/oracle-l