Justin Cave allegedly said,on my timestamp of 4/06/2004 6:11 AM:
- Application servers can be scaled out more easily than can database servers. Throwing an extra machine or two in the application server cluster is a relatively simple operation. Throwing an extra machine into a database server cluster, particularly if you're not using RAC everywhere, is much more complicated. Realistically, very few applications need this sort of scale out, but there are a few.
But nevertheless, very few. Which makes the architecture of "one size fits all" absolutely moronic. It never was designed to fit all sizes and it is only needed for a VERY SMALL number of situations.
pain. Overall, though, it is so much easier for a competent PL/SQL developer to add the appropriate constraints to a table than for a Java developer to write and maintain those same constraints in the application, that most projects will end up being delivered more quickly leveraging the database, even if you have to deal with this mismatch. Convincing developers of this, though, can be a challenge, since the mapping layer tasks are obvious on the schedule and the efficiencies that database-centric development provides are more amorphous.
I'm not sure that keeping all business rules in the database layer is a good solution either. I'd rather keep the data integrity rules IN the database, and off-load the TRUE business rules to the app server.
Does the "rule" apply to ANY application that may access that piece of data? Yes? Then it belongs in the database. No? It belongs in the app server with the code for this particular application.
And I'm still convinced the problem has to do with the o-r-mapping only and nothing else.
-- Cheers Nuno Souto in sunny Sydney, Australia dbvision@xxxxxxxxxxxxxxx ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
