## Mike Sofen (msofen@runbox.com):
> I look at this from the opposite direction: with a stable database
> API (via stored procs), I can change the schema and logic within the
> procs without causing any app code breakage…the app tier is completely
> insulated from those changes – that’s worth a lot.
Many applications are not designed to have a "stable" database API.
And suddenly... there's not only dependencies between functions
in the "core application" but also between application and database,
in more ways than "just a few tables". One needs to be aware of
that.
> Our dedicated db servers have not yet shown any real CPU consumption
> during app use - memory, for us, is the only real limiting factor.
That depends on the usage pattern. An application for "company internal"
use will behave quite differently from a popular internet application.
I do know of cases where too much code in the database became the
number one problem.
What I'm saying is: choose wisely, and be prepared for the day where
all your assumptions will be proven wrong. Predicting future use and
changes of an application in an emergent field is near impossible.
Database-side code can be a great thing, and a real problem. In the
worst case, it's both at the same time.
Regards,
Christoph
--
Spare Space
