Re: Novice MySQL problem

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