chris that quote if I remember right is in both Tom's book and website
and I have read about it quite a few times :D
Printable View
chris that quote if I remember right is in both Tom's book and website
and I have read about it quite a few times :D
Any day you can take credit for jmodic's work is a good day! http://www.theunholytrinity.org/crac...grinbounce.gifQuote:
Originally posted by chrisrlong
As Mr Hunter pointed out..
Quote:
One of the arguments for PL/SQL approach would probably be a higher level of abstraction and much higher level of flexibility.
Doh! :DQuote:
Originally posted by marist89
Any day you can take credit for jmodic's work is a good day!Quote:
Originally posted by chrisrlong
As Mr Hunter pointed out..
Quote:
One of the arguments for PL/SQL approach would probably be a higher level of abstraction and much higher level of flexibility.
My apologies to both of you ;)
And as for the portability:
I completely agree. There are specific types of applications where portability is the key. My concern is that that *most* people simply remember that 'somebody once said something about PL/SQL being bad for portability, so I guess we don't want PL/SQL'. In *most* applications, PL/SQL and abstraction layers are very, very important and portability is an afterthought at best. Of all the business-critical internal applications I've written or consulted on, I can't think of one where portability was a viable concern. So the point most people should take with them is that 'unless it is a stated requirement to make the system portable, do not forsake any other functionality in the name of portability'. That would be the starting point. Exceptions always exist, of course, but they are argued on a case-by-case basis.Quote:
Originally posted by TimHall
I hear what you're saying about portability, but I don't think it can be dismissed so easily. It really depends on the nature of the application.
It all depends on the App. The current application I'm at is off the charts in terms of volume of traffic, complexity of SQL, amount of data, size of reports... everything! And I have to optimize the damn thing with *no* abstraction layer!! Instead, we have tons of SQL strewn throughout tons of files in multiple applications in multiple languages. Converting to another database is actually *harder* without an abstraction layer because I would have to search out SQL which is often dynamically built in different languages, change *all* of it and then update *all* of these apps at the same time. If I had an abstraction layer, however, I could possibly keep the interface to the layer the same while pointing all the internals to the new engine. Not easy, but possible. If not, I would simply have to find and change a bunch of simple procedure calls, which is *much* easier than finding and re-writing dynamically-generated SQL in some obscure language. In the current situation, conversion is pretty much impossible. Unfortunately, so is changing even a single column name. Again, without the benefit of an abstraction layer, *everything* is more difficult, if not impssible.Quote:
Originally posted by TimHall
As for front ends, the majority of the SQL in web applications is trivial.
So again, I don't disagree that portability *can* be accomplished and that sometimes it *is* necessary. *Most* of the time, however, it is neither realistic nor necessary. So again, unless it is a requirement of the system, there are usually much more important things to worry about.
- Chris
[Edited by chrisrlong on 12-19-2001 at 04:46 PM]
There were some quotes from Tom Kyte's book and some discussion about SQL application portability in this thread, which reminded me about another Tom's mantra that can be found (if I remember correctly) in the first chapter of his book, and goes approximately like this: "There is (almost) no such thing as an *optimized* and portable SQL code". True, there are standards about SQL that most vendors follow (more or less), yet the internal processing of those SQL statements inside RDBMS is very different from vendor to vendor.
For example, read consistency or locking mechanism in Oracle is totaly different than it is in the SQL Server. So unless the whole application is realy the most trivial one, the developer must be very aware of the target database the application will use if the optimal performance is one of the goals.
It's a gross generalisation but, in it's simplest form you end up with one of two choices:
1) Take the approach that the application will look similar for each engine, but will be serviced by different underlying SQL & stored procedures.
2) Use the lowest common denominator so the application needs virtually no modification for different engines.
Neither choice can be considered more or less valid than the other depending on the REQUIREMENT.
chrisrlong seems to be saying, don't dismiss PL/SQL APIs just because someone mentioned portability issues one. I agree but, playing devils advocate I would say, don't assume you should use PL/SQL APIs until you find a reason not to.
You should arrive at the same conclusion whichever startpoint you use.
You're cursed if you do and you're cursed if you don't :)
I'm sorry, but I just can't let this one drop :D. Too many people are easily swayed by such things. They 'worry' about using PL/SQL or some other functionality because of things like this.
In it's simplest form, the way I see it is:
1) Portability is a requirement. In this case, you must make the choices stated by TimHall above.
2) The more STANDARD case is that portability is irrelevant. My point is that for most of the business-internal applications being written, which is the Lion's-share of the business, portability is pointless. There is no half-way here. Either you take advantage of the 1000 performance-enhancing differences of the engine or you don't. The *vast majority* of applications *need* these differences.
So the point is that unless portability is a stated requirement, forget about it. Trust me - you will *need* to use all the 'extras' that Oracle has to offer and you will thank me later if you build a nice abstraction layer now. :)
- Chris
Chris. Don't have a cow man!
These decisions are never made on a single issue. As I said, I don't disagree with you, but I think it is too easy to say always use it.
I'm currently in a position where I'm advising a group of VB programmers about improving performance on a system. One of the first suggestions I made was to use PL/SQL APIs for most of the functionality. Even the batch processing is currently done in VB. Unfortunately the developers involved have very little PL/SQL experience. This means they either take time to learn it, get someone in to do it for them or I do it. As none of these options are possible at this time they are carrying on with what they have. Yes, some concessions have been made but essentially the decision has been made to stick with an all VB approach. You can lead a horse to water etc.
You gotta larf!
:DQuote:
Originally posted by TimHall
Chris. Don't have a cow man!
Does that mean I'm forgiven for my wicked ways? :)Quote:
Originally posted by chrisrlong
:DQuote:
Originally posted by TimHall
Chris. Don't have a cow man!
Just for clarification....
I was 'speaking' more to the 'audience' in my replies than directly to you. I'm certain that you had reasons for the approaches you took. I am just looking out for more of the novices who are easily 'put off' from using wonderful things like abstraction layers because of mostly non-applicable concerns for things like portability. I just wanted to make sure that they had all the proper context with which to frame our specific debate.
'Don't have a cow, man'....
...cracked me up. :D
T'was a pleasure sparring with you, my good man. I look forward to 'having at it' again sometime ;P
- Chris