>On 09/04/2008, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
My point of view is that a database is for storage, not for logic...
From: "Graeme Geldenhuys Wednesday, April 09, 2008 3:35 PM
A very logical assumption. ;-) And one I fully agree with. Use the
correct tool for the job, hence the reason we don't use stored
procedures either.
Regards,
- Graeme -
Actually a hard-drive or other durable memory is for storage.
A database is for "efficient" organization of data to aid efficient
utilization
In most cases aggregation of that data is part of efficient utilization.
Aggregation of related data and several other math intensive ops inside the
DB engine (i.e. stored procs), will boost net performance VERY
substantially, when deployed in a properly cached and threaded environment.
Banks, Brokerages, Real Time Inventory managers, large store operations all
depend on these operations to be as efficiently as possible.
It comes down to knowing when, how and where to separate business layers of
integrated procedures relative to specific data sets so business logic that
is related is not in conflict with properly designed DB integration of
procs. But for the most general applications of DB's which do not rely on
mission critical performance, knowing how to apply DB internal procs and
functions is essential to large volume processing, timely. Otherwise, for
general purpose operation, DB's are simply a convenience over a mess of flat
files, so the question of procs is moot in these less demanding cases.
It doesn't mean Procs or Funcs don't belong in a DB, but that the need is
"application specific", especially where clock cycles and turn-around time
are critical.
Right tool for the right job. As much as ADO tried to benefit this idea and
basically broke the whole concept. ;)
Mike
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
