Re: views on views on views
From: Tim Gorman <tim_at_evdbt.com>
Date: Thu, 26 Mar 2009 17:56:35 -0600
Message-ID: <49CC1633.7030409_at_evdbt.com>
Who benefits from the concept of "database independence"? The customer? The end-user? The person using the application? No. Of course not. How? Why should they care?
It is the vendor, the developer who benefits from the ability to "easily port" from platform to platform. The reality of the phrase "easily port" is of course open to debate.
<rant>
When SQL is written to the lowest-common denominator of functionality, to the absolute minimum of common SQL functionality available, who is it that benefits? Who made that decision? Who thinks it is important? When the customer, the end-user, the people using the application have licensed a DBMS like Oracle which has a huge feature set above and beyond that absolute minimum set of functionality, why should they be pleased that the application is ignorant of those features for which they are paying so grandly?
I can understand where a vendor of COTS software would set "database independence" as a goal, but I am truly astonished at in-house custom-built applications which set this as a goal as well. After all, looking back over my 25-year IT career (and looking forward over the 15+ years that I hope remains), within organization I have seen migration from one database package to another moving slowly and carefully, at a rate of once per decade on average, if that. During the same periods, I have seen applications, even programming languages, flit in and out at a dizzying rate. What is the average lifetime of an application? Compare that to the average lifetime of a database package, particularly Oracle, within the organization. It is clear that, upon retrospection, in-house applications *rarely* have a need to be "database independent", but rather that databases have a need to be "application independent". Which they are (i.e. SQL*Net, two-task architecture, etc).
"Database independence" is at best a systems requirement, but it is not a business requirement, unless you are a vendor of COTS software. Systems requirements are supposed to support business requirements. To have application developers ignore the advanced functionality for which database software was purchased is a negation of the organization's intent by zealots. After all, if the choice of database was really based on the lowest-common denominator of SQL functionality, why would anyone pay for Oracle licensing? Why wouldn't everything be running on MySQL or PostGres or even Oracle Standard Edition?
I've often said that the closest thing to hell on earth in IT is to be the biggest customer of a small vendor. Especially when that small vendor is trying to become big by making their application code "database independent". I have been with customer executives as they questioned their vendor about the poor performance of the application, and have heard the small vendor respond that they cannot implement the requested fix because of "database independence" and portability issues. I've seen that conversation result in many different outcomes: sometimes the customer tosses the vendor out the door (which is a shame), sometimes the vendor's sponsors within the company win the day and keep the application, crippling the company.
</rant>
Long story short -- examine the "database independence" requirement very closely from the perspective of those who are relying on the application, and those who are paying for it.
Question authority -- especially IT people who have embedded the word "architect" into their job title...
-Tim Gorman
www.EvDBT.com
DBA Hole
Amar Padhi wrote:
Date: Thu, 26 Mar 2009 17:56:35 -0600
Message-ID: <49CC1633.7030409_at_evdbt.com>
I am always amazed at the tacit and universal acceptance of the phrase "database independence" as a good thing.
Who benefits from the concept of "database independence"? The customer? The end-user? The person using the application? No. Of course not. How? Why should they care?
It is the vendor, the developer who benefits from the ability to "easily port" from platform to platform. The reality of the phrase "easily port" is of course open to debate.
<rant>
When SQL is written to the lowest-common denominator of functionality, to the absolute minimum of common SQL functionality available, who is it that benefits? Who made that decision? Who thinks it is important? When the customer, the end-user, the people using the application have licensed a DBMS like Oracle which has a huge feature set above and beyond that absolute minimum set of functionality, why should they be pleased that the application is ignorant of those features for which they are paying so grandly?
I can understand where a vendor of COTS software would set "database independence" as a goal, but I am truly astonished at in-house custom-built applications which set this as a goal as well. After all, looking back over my 25-year IT career (and looking forward over the 15+ years that I hope remains), within organization I have seen migration from one database package to another moving slowly and carefully, at a rate of once per decade on average, if that. During the same periods, I have seen applications, even programming languages, flit in and out at a dizzying rate. What is the average lifetime of an application? Compare that to the average lifetime of a database package, particularly Oracle, within the organization. It is clear that, upon retrospection, in-house applications *rarely* have a need to be "database independent", but rather that databases have a need to be "application independent". Which they are (i.e. SQL*Net, two-task architecture, etc).
"Database independence" is at best a systems requirement, but it is not a business requirement, unless you are a vendor of COTS software. Systems requirements are supposed to support business requirements. To have application developers ignore the advanced functionality for which database software was purchased is a negation of the organization's intent by zealots. After all, if the choice of database was really based on the lowest-common denominator of SQL functionality, why would anyone pay for Oracle licensing? Why wouldn't everything be running on MySQL or PostGres or even Oracle Standard Edition?
I've often said that the closest thing to hell on earth in IT is to be the biggest customer of a small vendor. Especially when that small vendor is trying to become big by making their application code "database independent". I have been with customer executives as they questioned their vendor about the poor performance of the application, and have heard the small vendor respond that they cannot implement the requested fix because of "database independence" and portability issues. I've seen that conversation result in many different outcomes: sometimes the customer tosses the vendor out the door (which is a shame), sometimes the vendor's sponsors within the company win the day and keep the application, crippling the company.
</rant>
Long story short -- examine the "database independence" requirement very closely from the perspective of those who are relying on the application, and those who are paying for it.
Question authority -- especially IT people who have embedded the word "architect" into their job title...
-Tim Gorman
www.EvDBT.com
DBA Hole
Tim Gorman consultant - Evergreen Database Technologies, Inc. P.O. Box 630791, Highlands Ranch CO 80163-0791 website = http://www.EvDBT.com/ email = Tim_at_EvDBT.com mobile = +1-303-885-4526 fax = +1-303-484-3608 Yahoo IM = tim_evdbt
Amar Padhi wrote:
-- http://www.freelists.org/webpage/oracle-l Received on Thu Mar 26 2009 - 18:56:35 CDTJared,
I know of Java Architects who have designed web applications keeping data and application completely separate. One of them told me that this removes dependency on the database vendor. So tomorrow they can port and certify the application on some other platform. Well different school of thoughts... but then they are actually applying design concepts to have each tier do its job. And yes these guys use only Java against Oracle, no PL/SQL either. It was tough for me to digest this part.
Thanks!
amar
www.amar-padhi.com
On Thu, Mar 26, 2009 at 10:10 PM, Jared Still <jkstill_at_gmail.com> wrote:
On Thu, Mar 26, 2009 at 8:36 AM, Lyndon Tiu <ltiu_at_alumni.sfu.ca> wrote:
It depends what your school of thought is. But I believe the database should store raw data. It should guarantee contstraint and referential integrity. That's it. Any data manipulation/calculation/display should be in the application layer.
PL/SQL for data intensive manipulation?
(often much faster than external app layer - just return results)
--
Thanks!
Amar Kumar Padhi
Oracle DBA/Architect