Re: Using GUIDs - Mailing list pgsql-admin
From | Dennis Wagner |
---|---|
Subject | Re: Using GUIDs |
Date | |
Msg-id | 44A0E8B4.5090904@Spheron.com Whole thread Raw |
In response to | Re: Using GUIDs ("Aaron Bono" <postgresql@aranya.com>) |
Responses |
Re: Using GUIDs
|
List | pgsql-admin |
> By its definition, GUID ( http://en.wikipedia.org/wiki/GUID ) is not > guaranteed to be unique. As a result, it could cause problems in > tables that have a large number of rows - actually this could result > in hard to reproduce, seemingly random errors in your systems that use > the database. How does a GUID help you over a BIGSERIAL? It would help me in restoring archived projects. There is a quite frequent scenario where a once archived (e.g. in a file) subset of the db-contents will be restored. In that occasion I cannot be sure wether the bigserial-values the entries has before are free. One can easily imagine a system holding one project v(aka. subset of the content). Then one archives that projects, deletes the db, resets it's schema and then enteres two new projects. Afetr that, the once archived project is restored from the archive. That would most likely fail as the sequences will have given the same IDs (starting with 1) to elements of the other two projects. I would need a handmade merge which would really be painfull. Using GUIDs that use the MAC-adresses as well as the creation-time (as in version 4 of uuids e.g.) would most likely (I see, there IS the probability but I doubt it happing inside a common LAN, at least in the life-time of the product) create distinct GUIDS that would reside side-by-side without any trouble. > > Unless you are generating the PK in multiple databases, a BIGSERIAL > should act as a UUID. > > Maybe if you provide a little more detail on why you want to use GUID > or UUID fields we can help you come up with more options. > We're talking about a Client-Server-Application that would normally be run on about 10 to 50 clients simultanously using the same backend. Project-archivment will be frequent as single projects are open for approximatly one to three month. I'm well aware that as GUIDS are not really guaranteed to be unique there could be scenarios where double ID's would occur. But I could easily sense that before entering the project and then do this praticular one by hand. I don't want to do this on every project that is restored. As a second subject I will need to extract subsets of the content for external use in form of lists. Using the GUIDs of the entries would make them be more distinct and thus no addidtional numbering would be necessary for those lists. Currently I'm storing entries of different type in different tables. To have them distinct on a combined list I would need both the type and the id of a single row which would make up 16 Bytes if the type is bigserial as well (which it is in my scenario). > Thanks, > Aaron Thanks for your quick answer. Best regards Dennis
pgsql-admin by date: