Comments on: Goodbye, auto increment http://www.mitchitized.com/nerdy-stuff/goodbye-auto-increment/ the online home for mitch pirtle Fri, 30 Jul 2010 12:03:04 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Justin Dearinghttp://www.mitchitized.com/nerdy-stuff/goodbye-auto-increment/#comment-764 Justin Dearing Fri, 30 Jul 2010 12:03:04 +0000 http://www.mitchitized.com/?p=44#comment-764 [quote] Put more bluntly, right now the only databases that use auto increment are MySQL and Microsoft Access. Yes, there is a reason, and it ain’t a good one. [/quote]SQL Server has IDENTIY(), Postgres has sequences. 99% of the time these operate the same as autoincrement, with all the same problems. I doubt Oracle, Sybase and DB2 lack this feature by another other name. While popularity does not make this feature right.[quote] In the good ol’ days when I had to walk to school 20 miles each way in the ice and snow, naked, disk space was expensive and RAM was even worse. Then this kind of approach would have been appreciated as a cost cutting move. Nowadays? Fuhgeddaboudit. [/quote]DBs are one of the areas where this does not really apply. No matter how many gigs of music/video/word document I have I'm only using one at a time so there is a "fast enoiugh." When I have a blog, an accounting system, or something else, I want a billion people to be able to access said blog. I want to be able to store a millions of articles and billions of comments in one database. I also want to serve them to hundres of people a second. From that point of view, keysize matters. Of course, if you want to be able to shard and have an artificial key, even a a 96bit OID or a 128 bit UUID is smaller than most email addresses. [quote]
Put more bluntly, right now the only databases that use auto increment are MySQL and Microsoft Access. Yes, there is a reason, and it ain’t a good one.
[/quote]

SQL Server has IDENTIY(), Postgres has sequences. 99% of the time these operate the same as autoincrement, with all the same problems. I doubt Oracle, Sybase and DB2 lack this feature by another other name. While popularity does not make this feature right.

[quote]
In the good ol’ days when I had to walk to school 20 miles each way in the ice and snow, naked, disk space was expensive and RAM was even worse. Then this kind of approach would have been appreciated as a cost cutting move. Nowadays? Fuhgeddaboudit.
[/quote]

DBs are one of the areas where this does not really apply. No matter how many gigs of music/video/word document I have I’m only using one at a time so there is a “fast enoiugh.” When I have a blog, an accounting system, or something else, I want a billion people to be able to access said blog. I want to be able to store a millions of articles and billions of comments in one database. I also want to serve them to hundres of people a second. From that point of view, keysize matters. Of course, if you want to be able to shard and have an artificial key, even a a 96bit OID or a 128 bit UUID is smaller than most email addresses.

]]> By: Garyhttp://www.mitchitized.com/nerdy-stuff/goodbye-auto-increment/#comment-471 Gary Sat, 05 Dec 2009 13:12:44 +0000 http://www.mitchitized.com/?p=44#comment-471 As you pointed out, disk space is cheap, even if you have no use for the auto increment field for a table today, it costs nothing to include it. Course it also costs nothing to put on a couple of timestamp fields for created and updated. As you pointed out, disk space is cheap, even if you have no use for the auto increment field for a table today, it costs nothing to include it. Course it also costs nothing to put on a couple of timestamp fields for created and updated.

]]> By: mitchyhttp://www.mitchitized.com/nerdy-stuff/goodbye-auto-increment/#comment-29 mitchy Fri, 14 Aug 2009 04:17:01 +0000 http://www.mitchitized.com/?p=44#comment-29 It requires balance. My biggest beef with auto increment is that too many folks just think that is required for every table.In short, they don't seem to be modeling data anymore. If you don't want to bother yourself with the structure of your data, you should go schema-free, man! :-) It requires balance. My biggest beef with auto increment is that too many folks just think that is required for every table.

In short, they don’t seem to be modeling data anymore. If you don’t want to bother yourself with the structure of your data, you should go schema-free, man! :-)

]]> By: Andy Tarrhttp://www.mitchitized.com/nerdy-stuff/goodbye-auto-increment/#comment-28 Andy Tarr Thu, 13 Aug 2009 23:13:29 +0000 http://www.mitchitized.com/?p=44#comment-28 The problem with using something with meaning is that you better be sure it won't need to be changed and there are surprisingly few things that is true of. Changing a primary key, especially on a non-relational database, can be a real pain.I really like to be able to change user names, for instance. I had one user who got married and divorced 3 times in 7 years - and changed her name every time. Product ids, catalog numbers and even UPC numbers need to be able to change without creating a new record. Such a lovely feeling when you had to change a key piece of information like that and to find it wasn't used as a key.Still, you are right not to use auto inc indiscriminately. The problem with using something with meaning is that you better be sure it won’t need to be changed and there are surprisingly few things that is true of. Changing a primary key, especially on a non-relational database, can be a real pain.

I really like to be able to change user names, for instance. I had one user who got married and divorced 3 times in 7 years – and changed her name every time. Product ids, catalog numbers and even UPC numbers need to be able to change without creating a new record. Such a lovely feeling when you had to change a key piece of information like that and to find it wasn’t used as a key.

Still, you are right not to use auto inc indiscriminately.

]]>