| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: "We don't do triggers"
Volker Hetzer wrote:
Comments inline.
[SNIP!]
>> >>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!
It not just one customer - it's a complete branch (Banking, actually)
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.
Three: PL/SQL, TSQL and a front end (whatever)
>
>>And an app server is just that, be it 9iAS, TomCat or BEA - >>where does the "full blown" come in?
Well - if Daniel can with Forms, so can I
> How do I db-independently create a bitmap index in sqlserver?
Guess you don't. But hey - who needs 'em? :-v
> 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.
They do allow thin clients.
>
> 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
Again - many customers (and management pushing this down; talking about buzz levels!)
-- Regards, Frank van BortelReceived on Sat Nov 29 2003 - 08:47:03 CST
 |
 |