Re: Database Server Vs. Application Servers - Processing Location

Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<3F4381ED.32519001_at_remove_spam.peasland.com>...
> My personal feeling is that you should take advantage of the RDBMS
> strengths to make your application the best that it can be. Tom Kyte
> addresses this in his Expert One-on-one Oracle book.
>
> If anything, I'd put RDBMS-specific logic in stored procedures in the
> database. Then your application can be as vendor-neutral as possible,
> just calling stored procs. The stored procs can be as vendor-specific as
> you want. All you'd need is vendor-specific stored procs with your
> application.
>
> I've worked with lots of 3rd party apps. IMO, the best vendors are the
> ones who take time to engineer their apps for specific RDBMS versions.
> These apps cause the least amount of headaches when compared with apps
> that try to be vendor-neutral.

I think that is true up to a point. When the apps get over a certain amount of size, such as being integrated into an "Enterprise-wide" system, or some huge MRP system that's been evolving (or not :) since the 60's, there gets to be just plain too much code to get it all out before the RDBMS version is deprecated. Sometimes even when the vendor for the RDBMS is the same as for the app... :-)

So one way or another you need a layer between the app and the db, preferably one that is extensible for different vendor's strengths. Or, hey, why _not_ use a lowest-common-denominator approach? When it comes to the user, they don't really care as long as it seems to work for them. As a technical person, I find that revolting, but as a realist, there you go. Cheap and quick win over good most every time.

I think the SP approach got a bad rap when people started figuring out about ten years ago that that only works if the SP's work the same way (both internally and externally). That's difficult, and they tend to diverge more over time.

>
> Just my 3.14159265 cents worth,
> Brian

Yum, edible math with money. :-)

>
> Burton Peltier wrote:
> >
> > Just wondering what others opinions are on this subject...
> >
> > Within our company, there are some who think in-house developed applications
> > should be architectured such that there is no dependence on the underlying
> > database server software - the database server should only do CRUD
> > (create,read,update,delete) processing.
> >
> > This might at first seem sensible to some, I think there are way too many
> > "gray areas" to say the above should be a "standard" that must be adhered to
> > or have permission to do differently. I am guessing this is some people's
> > intent.
> >
> > Some people spend way too much effort trying to not "tie" themselves to 1
> > database vendor and don't take advantage of features and functionality (in
> > Oracle for our company), at a significant loss either by lost functionality
> > or performance or "writing their own way". Or, they do things like put hints
> > in the SQL to tune and are "tied" anyway.
> >
> > Note: I can see where a software vendor should/has to try and work this way.
> > But, this does not seem to make sense for a commercial company like ours.

Well, are you in the software business or some other business? You can only work at the level of _all_ your people. The trick is to be ready with a solution when the MBA discovers that his Access based forecasting program can't handle 65588 rows...

> >
> > --
>
> --
> ===================================================================
>
> Brian Peasland
> dba_at_remove_spam.peasland.com
>
> Remove the "remove_spam." from the email address to email me.
>
>
> "I can give it to you cheap, quick, and good. Now pick two out of
> the three"

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/wed/news/news_1n20privacy.html