Today I helped a client wrestle with a database task which concluded:
. . . We’ll have to watch out inventing new “fake” customers because one day there may be a real customer with our made up ID 😦
This is a problem in lots of apps, but not in Rails.
Rails enforces the “best practice” of giving every table a primary key named id, which is an auto-incrementing integer. But many non-Rails apps do not do this. Instead, they use some real-world data as the primary key. This is called a natural primary key. E.g., a customer’s social security number. There are arguments for and against this. This is a good little wikipedia page about the differences.
One big problem with natural primary keys is that they often turn out to not be as unique as we think. Plus, then we’re put in the position of “faking” the SS number when we want to manually add customers who don’t have one, e.g. “999-….”. (I remember a college I attended which assigned 999- SS numbers to international students.) And this is the hack that the task description refers to.
In contrast to natural keys, the id field is a so-called surrogate key. It intentionally has no meaning in the real world, and so it has no reason to ever change. It doesn’t matter at all what an object’s id is, just so long as it’s unique. And since it gets set up as an auto-incrementing integer, that will be the case.
So, Rails is “opinionated software” and has made the decision for us. Every table will have;
- a surrogate key,
- named id,
- which is an auto-incrementing integer.
And in one swoop, a whole category of potential problems is eliminated. Secondly, this makes it very easy to get up to speed on a new Rails app.
Dogweather 