I feel that this should be required reading for anybody who works with databases or business logic…so, you know, pretty much anybody who reads Lobsters. :)
The article attempts to rigorously go from a schema that supports “common-sense” notions of marriage (whatever that means) and then to finally achieve maximum flexibility and accommodation. It’s a really great exploration of “Okay, we thought we had these constraints, but we really didn’t, so what now?”.
On the more squishy side of things, I enjoy this article both because it helps people with more limited definitions of marriage see other arrangements and how they might be supported, and because it helps people that support nontraditional (again, whatever that means) arrangements understand just how complicated nominal support for such things could be (and thus to have empathy with folks who complain about the complexity in understanding these things).
I’ve never really liked this article.
From a database design perspective, it spends far too much time on obviously stupid ideas, such that it’s tiresome to read.
From a humanitarian rights perspective, I’ve never met a “traditional” marriage advocate who was particularly concerned with database schema.
From a learning standpoint, “obviously stupid ideas” can be pretty helpful to a somebody trying to backtrack reasoning.
Also, obviously stupid ideas have a weird way of unerringly making it into production. :)
I don’t strictly disagree, but has anyone ever made a database with separate tables for men and women? It seems a poor starting point for our journey of learning.
I wanted to dig up a slide deck I once saw which gave many examples of actual database decisions around things like gender marker, race, and other demographic parameters, and made points about how the choice of schema can’t avoid being political. Unfortunately, I don’t remember the author and can’t find it.
I agree with you that this present article is less interesting than it could be. :)
in Australia, the Marriage Act 1961 was amended (in 2004!) to define marriage as:
now, that is no longer a popular definition, but if i handed you a spec which read:
you wouldn’t be entirely insane to start by sketching two boxes for ‘widget’ and ‘flurble’ and a ‘gizmo’ line between them representing the 1:1 relationship. Of course, this ignores our domain knowledge that both ‘man’ and ‘woman’ are types of ‘human’, but then again perhaps that is just our modern perspective showing :-)
I don’t think domain knowledge there is even necessary. Given that in the original schema the
malesandfemalestable were the same except for a differenthusband_idorwife_id. Inherently you should reach for combining those two and adding some sort of “type” field.I think your gizmo/widget/flurble example only works when widget and flurble have very different data attached to them, instead of basically the same data with a few special cases that could easily be merged together.
Merge submission?
That’s only really useful when duplicate stories (or similar stories from different places about the same subject) are posted in a short timeframe, to consolidate discussion. It’s ok to re-post an old story, especially if it’s been recently updated or there is something new to say about it, and merging old discussion would just be confusing.
Ah, got it. Thanks.
This only got one upvote two years ago, so I figured the community deserved a second chance to see it. :)
Posted a hair early for Loving Day, which would be trivially (and poetically) modeled as the removal of a constraint.