Wandering Thoughts archives


There are two sorts of standards in the world

There are two sorts of standards in the world; let us call them forced standards and voluntary standards.

With a forced standard, someone makes you adhere to the standard. If you don't, you can't get your product licensed or certified or whatever, and you can't sell it or give it away or do whatever you want to do with it. Sometimes this is forced because of legislation, and sometimes this is just forced through the marketplace; no one will buy your product if it is not certified as whatever or if it doesn't work with other people's products.

(Note that it is perfectly possible for a de facto standard to be a forced standard because of interoperability requirements.)

With a voluntary standard, there is nothing in particular that makes you adhere to the standard. People adhere to the standard anyways because it's useful, because they're nice and like it, because it's good PR, or for a number of other reasons. They may also adhere to the standard only in part, picking the bits of it that they like or that they need or that are easy enough to implement.

Forced standards are the only sort of standards where you can write something that people have to implement (well, more or less; ask any home renovator about how many things adhere to building codes). This makes forced standards a very attractive idea to the sort of person who wants standards to lead from the front (to put it one way).

Mistaking what sort of standard you're dealing with or creating is a great way to get into a lot of trouble one way or another. On the surface it sounds relatively harmless to mistake a voluntary standard for a forced standard, but in practice it leads to a lot of aggravation all around and people can expend a great deal of effort in arguing about the situation (or, often, yelling at each other). At the extreme it leads to the creation of unwanted 'standards' that are a complete waste of time and effort.

(As with lots of things about standards, there is a continuum in practice. This is especially so if the forcing is happening because of market demands instead of legislation, since market demands change over time.)

tech/TwoSortsOfStandards written at 23:07:47; Add Comment

A little advantage of Django's automatic primary keys

If you don't specify manual primary keys on your schema tables, Django will automatically give you one in the standard form of an auto-incrementing integer. I believe that this is standard ORM behavior and you'll find it in pretty much any ORM interface. After coming to my SQL foreign key realization I've realized that there's an additional advantage to having this sort of primary key (over and above the ability to fix oopses in what is normally that table's primary key).

The advantage is simple: the primary key is unlikely to ever repeat, even after you delete entries.

(I think that technically you could have ID counter rollover, but this would require a lot of row inserts even with a 32-bit ID field.)

That the primary key doesn't repeat means that the primary key will uniquely identify a particular record even after the record is deleted. This is an extremely valuable property for historical records, such as audit log information. All you have to do is explicitly record the primary key value and you're done, you're now pretty much guaranteed to be able to accurately identify just what object you were talking about.

This property is not shared by many explicit primary key fields. While they might be unique in the live data, there's no guarantee that they will not repeat over time. For example, a simple account request system might use the requested login as the primary key on the grounds that you can't allow two requests for the same login. But then you have a request for a login name that is denied and deleted, and later you have another request for the same login; now any audit data or the like might be referring to two different requests.

So now I have two reasons to be happy that I've switched my Django schemas to not using explicit primary keys and let Django handle it for me.

(All of this is probably making SQL people twitch. Certainly it's doing that to the 'normalized SQL database design' portion of my brain.)

python/DjangoImplicitPKAdvantage written at 02:10:06; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.