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 Dallas
> 3ft9 Ltd
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