Apparently PragDave had the temerity to suggest at RailsConf that Rails could stand some improvement in some areas, such as supporting composite primary keys in ActiveRecord. Naturally, the first reaction of a huge Rails fan like Martin Fowler is to get to work figuring out how to implement this.
Whoops, sorry, no, that would be in some alternate universe where fanboyism isn't the most important technical prinicple for some people. Martin's real reaction was to write a rebuttal, the gist of which is, if Rails doesn't already support it, it can't be important.
It's sad when someone who's done some good work puts on the fanboy blinders. You used to get the same schtick from mysql.com back in the 3.x days. Remember the rants in their docs about how foreign keys and transctions were for wimps and real programmers didn't want them anyway?
Of course, today even mysql corporate admits that these are important features, even though one can be forgiven for having a sneaking feeling that they don't really understand exactly why some people make such a big deal over it. Presumably once Rails supports composite primary keys we will hear Martin singing a different tune. One can only hope it won't be the sort of half-assed bullet point it is for MySQL (where you can have transactions and FKs and so forth, all right, as long as you don't use the default table type).
Anyway. Josh Berkus (a member of the postgresql core team) recently wrote a thorough, three-part series on exactly this subject (composite primary keys, if you recall):
If you're a typical I-prefer-to-not-think-about-the-database-until-something-goes-wrong developer, this series touches on a lot of issues that will really make you think.
Oh, and if you couldn't guess what Josh thinks of the "just use a surrogate [integer] key" approach...
The surrogate numeric key has been a necessary evil for as long as we've had SQL. It was set into SQL89 because the new SQL databases had to interact with older applications which expected "row numbers." It's a bit of legacy database thinking that, according to a conversation with Joe Celko, E.F. Codd regretted allowing to creep into the SQL standard.
Inevitably, practices which are "necessary evils" tend to become "pervasive evils" in the hands of the untrained and the lazy. Not realizing that ID columns are a pragmatic compromise with application performance, application developers with an shallow grounding in RDBMSes are enshrining numeric IDs as part of the logical and theoretical model of their applications. Worse yet, even RDBMS book authors are instructing their readers to "always include an ID column," suturing this misunderstanding into the body of industry knowledge like a badly wired cybernetic implant.
Some eye-opening stuff there.
(And I don't want this to be a my-ORM-is-better-than-yours post -- really! -- but I know somebody will ask, so yes, SQLAlchemy does support composite primary keys.)
