[Lazarus] Reading result of a Firebird stored-procedure

[Graeme Geldenhuys]

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.

* 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.

NOTE: there are other pros to using GUID's.  So too are there
negatives to using DB generate/managed sequential numbers.

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.



-- 
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net