[Lazarus] Reading result of a Firebird stored-procedure

[Martin]

On 07/03/2011 22:38, Michael Van Canneyt wrote:
> On Mon, 7 Mar 2011, Graeme Geldenhuys wrote:
>>
>> * As for joining tables being slower. This is so, but the margin is so
>> small for day-to-day usage than nobody notices any difference really.
>> We tested our system with between 30-60 concurrent users working on
>> our system for 8 hours a day, on a low spec workstation acting as a
>> database server.
>
> You'll find that as the system grows, the difference becomes significant.
> One of databases is currently between 4 and 5 Gb. It no longer fits in 
> memory, so disk access becomes an important factor.
>
>> NOTE: there are other pros to using GUID's.  So too are there
>> negatives to using DB generate/managed sequential numbers.
>
> Definitely. Replicating for instance is next to impossible with 
> generators.
> It's much easier with GUIDs.
>
>> The bottom line for us was that the pros far outweighed the cons.

There are good solutions in the middle.

Generate a guid in your own limited size format. Either on the DB, or on 
the client, both will work.

The IDs can be unique 32 or 64 bit integers depending on the amount of 
IDs needed.
In order to be able to generatethem unique and generate them on more 
than one computer (e.g each client pc can generate them) you need to 
configure each of the generating computers.
Each of them is given a on byte (or one word) ID of it's own.

Then Each PC just generates numbers in sequential order, to be used as 
ID. Shift it 8 or 16 bit, so you can put the unique-computer ID in the 
low byte(s) => unique ID. And at moderate size and cost.

Martin