On Mon, Nov 14, 2011 at 4:11 AM, Stuart Dallas <stuart@xxxxxxxx> 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
