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


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to