[fpc-pascal] Looking for a Firebird book?

[afpTeam]

> >On 09/04/2008, Michael Van Canneyt <michael at freepascal.org> 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