Re: "We don't do triggers"

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 28 Nov 2003 09:41:03 -0800
Message-ID: <1070041292.977506@yasure>

Volker Hetzer wrote:

> "Frank" <fbortel_at_nescape.net> schrieb im Newsbeitrag news:bq7di2$u7u$1_at_news3.tilbu1.nb.home.nl...
>

>>Volker Hetzer wrote:
>>
>>
>>>"Frank" <fbortel_at_nescape.net> schrieb im Newsbeitrag news:bq7a4f$itk$1_at_news1.tilbu1.nb.home.nl...
>>>
>>>
>>>>Volker Hetzer wrote:
>>>>
>>>>
>>>>>"Frank" <fbortel_at_nescape.net> schrieb im Newsbeitrag news:bq5pa7$bnj$1_at_news1.tilbu1.nb.home.nl...
>>>>>
>>>>>
>>>>>
>>>>>>Volker Hetzer wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"Frank" <fbortel_at_nescape.net> schrieb im Newsbeitrag news:bq34ho$qr$1_at_news4.tilbu1.nb.home.nl...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>What if you have customers that wish your product to run
>>>>>>>>on a variaty of backends?
>>>>>>>>Makes sense to put (1 version!) of the business rules in
>>>>>>>>the middle tier to me. Use the database just as a pool of data;
>>>>>>>>no logic
>>>>>>>
>>>>>>>What if they wish to use a variety of middle tiers?
>>>>>>>
>>>>>>>Greetings!
>>>>>>>Volker
>>>>>>
>>>>>>I tell 'm I don't do that ;-)
>>>>>>Seriously - the customer can have any middle tier as long as
>>>>>>it's black - sorry, Java.
>>>>>>
>>>>>>The background of all this is simply a matter of
>>>>>>development cost - it's cheaper (at least, thought to
>>>>>>be!) to develop the logic in one flavour (Java), than in,
>>>>>>say two or three (Oracle: PL/SQL, SQL Server: TSQL, DB2/MySQL/...)
>>>>>
>>>>>But look, who prevents the developer from using java stored procedures
>>>>>in the db if he wants to use java? That's no reason to do an app server!
>>>>>
>>>>>Greetings!
>>>>>Volker
>>>>
>>>>SQL Server has Java in the db? Since when.
>>>
>>>It doesn't? Well, it's microsoft after all...
>>>One more reason not to have anything to do with it.
>>>
>>>
>>>
>>>>And Orace seems to have plans to remove it from the db.
>>>
>>>Just had a short look, didn't see anything about it. Where
>>>did you get it from?
>>>
>>>Back to topic, so your sole motivation is to use some server
>>>to get around portability problems? In that case you've got
>>>two solutions:
>>>- Mysql. Get it for your platform and you're done. Fast,
>>>   reliable, supports replication, etc.
>>>- I'm not sure but I think, for portability problems there ought
>>>   to exist much slimmer solutions than a full blown appserver.
>>>
>>>Greetings!
>>>Volker
>>
>>We're losing the subject here - it's about commercial thinking
>>and opportunities.
>>There's a request to support SS2k as well as Oracle. There's also
>>a request to support the app as a web based app.
>>s/request/demand/g
>>
>>Let me put it another way: how would you propose to do it?
>>No MySql by default - SS2K and O9i, too!

>
> Ok, first I'd try to convince my customer to agree to one
> platform. Typically that's done by saying "this app requires
> oracle". If one customer wants several different dbs, I'd listen
> to why. If they come with safety or something it should be
> pretty easy to tell them that in their configuration the appserver
> represents the biggest risk (less established than the databases)
> and a single point of failure. If they just can't make up their minds,
> support the cheapest and call it done. If they say "but we have
> already sqlserver", then it's a maintenance/administration issue
> and you can do the mysql-version. Anyway, if one user demands
> from you to support two different databases, it's like demanding that
> you implements some program in two different languages.
>
>

>>And an app server is just that, be it 9iAS, TomCat or BEA -
>>where does the "full blown" come in?

>
> So, if you decide to use 9IAS, you can support oracle and SQLServer?
> How do I db-independently create a bitmap index in sqlserver?
> BEA looks all right but it's the "full blown" one too. If you want to
> let this one loose on the user, you might as well let him have oracle
> or db2 instead of bea *and* two different databases.
> I've seen their overview and it's certainly buzzword compliant
> but they've reinvented about every wheel of the last three decades.
> That's exactly what irks me so when I hear about appliaction
> servers. First there was files. Then someone came along and said "hey,
> what about providing a unified, powerful interface to search those
> files, change them in a consistent way and implement logic and set
> theory on the data?" And they called this database and it was great
> to implement all sorts of rules, business or otherwise. And on
> every platform it's been ported to you can use the same features.
> An appserver is exactly the same, only its "files" are dumbed down
> tables. But it still needs to be ported, there are still several incompatible
> ones around and one day an user will figure out that all the important
> stuff goes on in the application server and will say: "But I want your app
> to support two different app servers!" What then? Microsoft will die
> before they support java in any meaningful way but it might one day
> do an application server. Will there then be pre-app-servers, dumbing
> down the app-servers? You see, app-servers don't solve problems, they
> time-shift them while costing money.
>
> As how I'd do it, I'd probably do a survey on who wants which
> db and then code for it. I've NEVER heard of a company that
> wants for instance to replicate across different databases. The
> combined reliability of two different databases being forced to
> talk to each other, however indirectly, plus some broker
> software (your app-server) is much too low for a mission-critical
> application. If people really want that kind of security, they will
> spend money on two different applications, implemented by
> different people. I could imagine NASA doing this with a manned
> mars mission or the DOD with the nuke release codes but not
> many other customers.
>
> Lots of Greetings!
> Volker

I'm in comlete agreement with Volker. In fact I have some serious doubts about a client that asks for a solution that supports two different RDBMS products that are so completely different in architecture as Oracle and SQL Server. If it was SQL Server and Sybase I could buy it. But this is, at best, a case of a customer that needs a strong dose of education.

 From my experience the requirement is nonsensical.  From my experience the solution is equally so.

Which doesn't mean that I haven't consulted for companies that built their product to run on multiple RDBMS's. But each and every one has tried it Frank's way and then hired me to help them undo the mess they made.

So go for it Frank. Do it your way. You have my email address when you discover that you can't do the same thing to a database with row level locking, lock escallation, and non-atomic transactions as you do with a database that has no lock escallation, atomic transactions, and MVCC.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Fri Nov 28 2003 - 11:41:03 CST