Re: "We don't do triggers"

"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 Received on Fri Nov 28 2003 - 07:35:32 CST