[symfony-users] Re: Using UUIDs for primary keys vs AutoIncrementing/Sequence based primary keys
On 4 Gen, 13:41, Gareth McCumskey gmccums...@gmail.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
[symfony-users] Re: Using UUIDs for primary keys vs AutoIncrementing/Sequence based primary keys
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 garak...@gmail.com wrote: On 4 Gen, 13:41, Gareth McCumskey gmccums...@gmail.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
Re: [symfony-users] Re: Using UUIDs for primary keys vs AutoIncrementing/Sequence based primary keys
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 gear...@sbcglobal.net 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 garak...@gmail.com wrote: On 4 Gen, 13:41, Gareth McCumskey gmccums...@gmail.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.comsymfony-users%2bunsubscr...@googlegroups.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
