[Lazarus] Reading result of a Firebird stored-procedure

[Michael Van Canneyt]

On Mon, 7 Mar 2011, Graeme Geldenhuys wrote:

> 2011/3/7  <michael.vancanneyt@***>:
>>
>> Correct. (well, not 100%, because GUIDs are never guaranteed to be unique,
>> however, the possibility that 2 of them are the same is very small indeed).
>
> Very small indeed. :)
>
>
>> A noticeable downside is that indexes are WAY bigger, and the queries
>> joining
>> different tables are slower, and you loose the order of creation of records.
>
>
> * creation order can easily be worked around by saving data with a
> timestamp or something - that's if creation order is actually
> important. In our applications a timestamp is suitable enough.

True, but this means an additional field, and an additional index,
on top of the 'already-heavy' GUID field and index...

>
> * 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. Your
> mileage my obviously vary. I would recommend each company evaluate
> there own needs. I just thought it might be beneficial to the original
> poster, to mention an alternative option for DB generated/managed
> primary keys.

Absolutely. 
Better to make an educated decision than one made in the dark...

Michael.