From: Eduardo E. <eel...@na...> - 2004-05-12 15:35:42
|
David Warnock wrote: > Luke, > > A lot depends on the problem domain. In a corporate environment the > database is often used by multiple applications and has a longer life > than individual applications. Therefore logic in the database is cheaper. > > Anyway, if you dbms does not have triggers choose a proper dbms ;-) I don't agree. In my case, it used to be so two or three years ago. Nowadays, most of my customers want business objects residing in an application server and I've been relatively successful implementing this concept with Webware/Python (and this is why I'm starting to use SQLObejct). In fact, thats the whole idea in Java EE and Web Services, in which I've completely achieved that: various applications/clients using an application object implementing business rules. Part of the explanation for this is databases are not that "stable" any more. For instance, one of my customers (a large company, by my country standards) is favoring MS SQL Server, because of Oracle licensing price changes. Now they find they have to migrate database code if they want to get rid of Oracle. Other customers are migrating to OS database systems (MySQL, Postgres). Yet, other customers complain when the find their application code is not "centralized", but scattered in application programs, database code and batch tasks. The new rationale is: let's put the code in application code, so we get a single application source which we don't have to migrate/rewrite the next time we upgrade/switch DBMS (Oracle/SQL Server to OSDMBS) or client (windows, html/javascript, WAP, etc). > Maybe one day there could even be a deployment option to choose which > SQLObject code runs in the client and which in the dbms as triggers ;-) > > Dave By the time being, I would be very grateful if someone can give some pointers on how to implement this trigger functionality for SQLObject. Luke has given me some. May be later I could post a patch or something in return for the help. Regards. Ed. |