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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
