On Mon, Nov 14, 2011 at 4:11 AM, Stuart Dallas <stu...@3ft9.com> wrote: > On 14 Nov 2011, at 11:47, Jim Giner wrote: > >> Actually, no it doesn't, since I have a well-developed sense of all of >> that, but that's not helping to answer the OP's question now, is it? Stay >> on point. > > The OP's problem is solved, so the point is no longer relevant. > > I'm curious to know what your "well-developed sense of all of that" does when > in lieu of auto-incrementing fields, and why. > > The only legitimate reason I've ever come across to avoid them is when you > expect to need to partition data across multiple master DB servers. Is this > why you avoid them? > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > >
Even with clustering, not comparing inherent clustering technique between RDBMSes, consider the following (MySQL) table example: CREATE TABLE `my_cluster_sample` ( `pkID1_AutoInc` bigint(11) NOT NULL AUTO_INCREMENT, `pkID2_SrvrID` int(11) NOT NULL DEFAULT '1' COMMENT 'Use # of designated server ID', `name` varchar(50) NOT NULL, PRIMARY KEY (`pkID1_AutoInc`,`pkID2_SrvrID`) ) The only reason that I see where not to use integer types with auto increment for PK is when you have an insane _LARGE_ number of rows, in any given DB instance/server. Then, the integer type no longer applies and the use of GUID/UUID or other surrogate types comes in, aside from getting into hot debate/discussion about pros & cons of natural vs surrogate keys even if you don't have large amount of data ;) Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
