I prefer Hillel's implementation using SERIAL. It's guaranteed to be unique within the database. User/application generated unique id's aren't a good idea, and have no advantage over a database SERIAL in this instance.
Alexander Malysh wrote: > Hi Enver, > > > Enver ALTIN schrieb: >> I guess this may wreak havoc if someone insane decides to connect >> multiple bearerbox instances to a single database server, because there is >> little chance that two different bearerbox instances creating a >> not-so-universally-unique-ID that may clash. > > this is not true. UUID is to 99% unique even in a cluster. We have log tabel > in the DB with over 500K inserts per day and UUID will be generated not only > by one instance and I never seen clash since 2years. > >> >> Personally I like the serial column approach. >> >> -HTH >> >> On Tue, Jun 24, 2008 at 12:45 PM, Alexander Malysh <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Hi, >> >> would it not be easier to use our UUID instead? I have patch in my >> tree, will try to extract it... >> >> Thanks, >> Alex >> >> Guillaume Cottenceau schrieb: >> >> "Hillel" <hillel 'at' ecommunicate.biz >> <http://ecommunicate.biz>> writes: >> >> Hi, >> >> Guillaume I agree it's not so clear from the documentation >> below, but as far >> as I know the CTID is the physical position of the row >> inside the heap. >> Every UPDATE and some VACUUM operations can affect it. >> >> Even if the CTID may be stable over a DELETE as of today, >> some future >> storage engine development (like HOT enhancements) may put >> an end to that. >> In general, the CTID is not guaranteed to remain the same >> unless you hold a >> FOR UPDATE lock on the row. >> >> >> True, though the net result is really similar to the previous one >> with OIDs. I guess it boils down to knowing why OID why chosen >> over a proper SERIAL column in the first place, and I don't know >> the reason for that (I could find no relevant information in the >> mailing-list archive; though, I guess the reasoning was to have a >> unique way of creating the kannel DLR table, not one per database >> engine; however, on that question, the approach proved its limit, >> IMHO). If OID was fine, I think CTID is fine, since it has a >> similar behaviour (and I don't think concurrent UPDATEs on the >> dlr table is a supported usage pattern). If we want to be safe, >> and we can afford a different way of creating tables per database >> engine (which is already the case btw, due to the INT(10) >> difference) then of course, using a proper SERIAL column is the >> best decision. >> >> >> >> >> >> >> -- Enver > > ********************************************************************** --------- NOTICE --------- This message (including attachments) contains privileged and confidential information intended only for the person or entity to which it is addressed. Any review, retransmission, dissemination, copy or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient, is prohibited. If you received this message in error, please notify the sender immediately by e-mail, facsimile or telephone and thereafter delete the material from any computer. Metropolitan Health Group, its subsidiaries or associates, does not accept liability for any personal views expressed in this message. Metropolitan Health Group PO Box 4313 Cape Town 8000 Tel: (021) 480 4511 Fax: (021) 480 4535 www.mhg.co.za **********************************************************************
