Just be careful of blindly using a specific system for your primary key ids.
Everything you said is absolutely true ... if you need it. We have used
character based ids before but only when we absolutely had to because the
benefits were critical to the running of our application. In my experience,
90% of cases do not require use of characters and integers are sufficient,
even across multiple db's.

To respond to Mass, 4 characters is reached really quickly (again depending
on how active your app is). For our purposes efficiency is the number 1
priority because we create something like a few thousand records a day.
Having to have a programmatically generated and inserted id is far too slow
for our needs as well as doing searches across a CHAR column.

On Tue, Jan 4, 2011 at 8:46 PM, Dennis <[email protected]> wrote:

> Well, there are quite a few good reasons to use UUIDs.
>
>   1. It is unique for the current domains. As a primary key it
> uniquely identifies the table
>   and or databse in distributed applications.
>   2. Less chances of for duplication.
>   3. Suitable for inserting and updating large amount of data.
>   4. Easy for merging data across servers.
>   5. The thing that UUIDs buy you that is very difficult to do
> otherwise is to get a unique
>  identifier without having to consult or coordinate with a central
> authority
>   6. When displaying row ids in public intefaces like the web, or
> easily
>   examinable APIs, obfuscated IDs prevent or make difficult:
>      A/ Sequential scraping of data.
>      B/ Knowing CURENT size of data or customer base.
>      C/ Observing GROWTH of sizeof data or customer base.
>   7. Since any row identifying primary or secondary key has to be
> unique,
>   the database designer might as well use the obfuscated ID as the
> primary
>   ID.
>   8. In large, multinationally distrubuted applications,, #5 above is
> very
>   important, especially during replication and merging of databases.
>
> So as always, if the ADVANTAGES out weigh the disavantages, then
> UUIDs are the correct choice.
>
> More on this subject, (and do google on UUID vs Integer.
>
> http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
>
> http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
>
>
> On Jan 4, 6:13 am, Massimiliano Arione <[email protected]> wrote:
> > On 4 Gen, 13:41, Gareth McCumskey <[email protected]> wrote:
> >
> > > To be perfectly honest, why bother? What advantage does turning a more
> > > efficient integer based, autoincrement ID column into a more
> inefficient,
> > > multi-byte character column, even if you could get "autoincrement"
> working
> > > for characters? Any app that requires a unique ID for the primary key
> should
> > > work fine integers. Characters just make database slower.
> >
> > You can find discussions on mysql forum, stating that char key is
> > slower than integer key only if char is longer than 4.
> > IMHO a char primary key is nice when you need a key that is human
> > readable (e.g. for a state/province)
> > I used it myself with any problem.
> > Of course, you need to specify by hand a key value when/if you insert
> > a new row, but that's all.
> >
> > cheers
> > Massimiliano
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony users" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<symfony-users%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-users?hl=en
>



-- 
Gareth McCumskey
http://garethmccumskey.blogspot.com
twitter: @garethmcc

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to