Gay marriage: the database engineering perspective

I can't say I've even <i>seen</i> a database that had redundant man/woman tables in this way. Regardless of where your politics lie on the issue, it's a violation of normal form with no benefit and any number of inherent problems.<p>When I was writing code for a medical facility, the guy who designed the database was as straight-laced and socially conservative as you'll meet.<p>But his design handled same-sex marriage/bigamy/polygamy/transgender issues, etc.<p>(It was a mental health facility. You get all sorts of interesting data problems when tracking the outliers.)<p>His philosophy on the design --and I'd imagine this isn't so odd amongst geeks-- was that data was data and needed to be tracked in a proper and robust manner, regardless of rightness or wrongness or personal feelings.<p>Assuming a male/female table is a reasonable logical starting point because 'some people feel this way' is akin to suggesting redundant christian/muslim/dirty_atheist tables would/should be expected to occur in professional code, because 'some people feel this way'.

So we start with "how to put gay marriage in a database" and end with "marriage is a union between any number of people, where people can come and go as they please." By that definition, I could be married to the company where I work.<p>Truly, an obliteration of any meaning to the word "marriage."<p>Really, I think we should start over. What is marriage, in the eyes of the state? Why should it grant special privileges to encourage it? Does society reap benefits from having a man and a woman committed to each other? Does it benefit from having eight people of varying sexes and self-declared genders semi-committed to one another in varying degrees? Are we prepared to draw a line somewhere and - gasp! - judge some unions better than others?<p>If we don't have widely-accepted answers to that, maybe we should stop recognizing marriages legally, substitute designations like "this person can make decisions for me if I'm ill," and leave marriage to be a religious designation only.

The author is actually outlining a new market for programmers. This is akin to fixing the MMDDYY errors in databases that brought the Y2K phenomenon (one part factual basis, two parts hype and hysteria). We could call it "Y2Gay".<p>But, I agree with other posters here. While MMDDYY was indeed pervasive, I've seen very few DB designs that assume role/gender at the schema level. That said, I would not be at all surprised to find logic or 'validation' that would choke on "MM" or "FF" or "was M but now F".<p>Y2K made lots of consulting firms (as well as retired mainframe programmers) quite profitable during 1998-2000. Here's to new opportunity. :-)

Just another reason to use object databases:<p><pre><code> role Person { has qw/age height weight serial_number/ } class Man with Person { has 'length' } class Woman with Person { has 'size' } class ... # whatever else people can be # assume index on "does Person" set my $bob = $db-&#62;get_person('Bob'); # isa Man my $harry = $db-&#62;get_person('Harry'); # isa Man my $sally = $db-&#62;get_person('Sally'); # isa Woman # i think there was a movie about this txn_do { my $m = Marriage-&#62;new( people =&#62; [$harry, $sally] ); $harry-&#62;add_marriage( $m ); # in real life, there is a trigger on $m-&#62;add_person that does this $sally-&#62;add_marriage( $m ); $db-&#62;store_marriage( $m ); # harry and sally are stored too }; # didn't work out. $m-&#62;annul( on =&#62; DateTime-&#62;now ); $db-&#62;store( $m ); $harry-&#62;is_married; # false $harry-&#62;has_been_married; # true $m2 = Marriage-&#62;new( people =&#62; [$bob, $harry] ); ... $harry-&#62;is_married; # returns $m2 my $tom = $db-&#62;get_person('Tom'); $m2-&#62;add_person( $tom ); # "three way" ... </code></pre> Anyway, object graphs make modeling all the possibilities pretty easy; with the right indexes (on people and marriages) it's fast, with the right data structures it's lossless (annul pushes the marriage onto a history for that person), and with the right triggers (adding a person to a marriage adds a marriage to the person) the data stays consistent.

Originally posted to HN when he wrote it shortly after the CA Prop 8 vote.<p><a href="http://news.ycombinator.com/item?id=371987" rel="nofollow">http://news.ycombinator.com/item?id=371987</a>

Wow, lots of non-database comments (not that there's anything wrong with that).<p>Design your systems flexibly, with a reasonable lack of assumptions. If society moves past your system, fix it.<p>I have one name. <i>Very</i> few online forms have ever allowed me to leave first or last blank. I generally try to get away with first-blank, last-filled in, and then surrender as appropriate.<p>What's worse, I think, is online groups where only one person can be known by a particular name. Stupid. How you call yourself should be unrelated to how the database needs to identify you uniquely.

Another reason to oppose gay marriage: the stable straight marriage problem is solvable, and there is a fairly simple algorithm to solve it. It heavily uses the fact that preferences form a bipartite graph.<p><a href="http://en.wikipedia.org/wiki/Stable_marriage_problem" rel="nofollow">http://en.wikipedia.org/wiki/Stable_marriage_problem</a><p>In general, the stable roommate/gay marriage problem does not always have a solution.<p><a href="http://en.wikipedia.org/wiki/Stable_roommates_problem" rel="nofollow">http://en.wikipedia.org/wiki/Stable_roommates_problem</a>

Another case for NoSQL databases. (Actually I have no clue how to solve this but, I felt like no HN database discussion would be complete without it.)

That's the stupidest rationalization I've ever heard for why we should continue to deny basic equality to a significant portion of the population.