#y2gay

[shlongus]

[b0y-o-blog]

[cummies4dummies]

damn i was really hoping when i woke up this morning this app would just be magically gone from my life

[mrberre]

The lesson is not "prepare for every possible eventuality". The lesson is to become comfortable and confident in modifying your schemata without losing data, and rolling back botched changes. Do this regularly, so that it becomes second nature. The lesson is to get used to change.

And what is true of our databases is also true of our world views. The future is vast and humans are creative. Things are going to happen which nobody could predict. It's going to be fun!

[anthropohedron]

Yes, it's Y2Gay if you're a DBA or software developer dealing with representing data about US citizens and their spouses. There are some insights here even if you don't follow the specific technical stuff.

[renerdssanceman]

Today I learned about (or at least learned a lot more about) the massive database problems that the Supreme Court just caused a few days ago.

The writer at qntm.org (who, per a copyright notice on the site, is just named “Sam,” so prepare for a slew of gender-agnostic pronouns) put together a big long meditation back in 2008 on the problems database engineers might face if/when same-sex marriage (and various other kinds of marriage farther down the slippery slope) were legalized. This is a problem helpfully and pithily known now as “Y2gay,” and Sam spends quite a bit of time iterating through possible schemas for representing marriages in a database, aiming toward a more inclusive and better-designed data management solution. 

The piece is very readable even to someone who doesn’t know a whole lot about databases, and wicked funny to boot. Long, but highly recommended. Sam also wrote a follow-up piece a few days ago after the Obergefell decision, available here.

Find Sam on twitter here; seems like a good follow.

[thinkthisthought-blog]

This database engineer breaks down the issues of marriage inequality in terms of expanding a SQL database (from 2008). Does a fantastic job of breaking down why defining (legally) who can be married to whom & how creates database schema & referencing issues; then explains how this relates to the more important issue of these definitions create obvious discrimination, as well as less obvious sexism within the traditional marriage ideologue.

The idea of breaking from traditional database schemas, categorization & information architecture is as important to technology as it is to human culture.

The logic steps taken in the above article reflecting how certain categorizations & the required cross-referencing to ensure that the rules of the categorization process are followed break the ability for certain types of databases to expand.

Creating a system wherein the traditional hegemony has set categories above & beyond the most basic necessary to define a set (above article: legal necessities to reference a marriage are reduced to on the human side: (per human) id#, name, surname & birthdate.  On the marriage side: marriage id#, partners id numbers, marriage date & divorce date, as applicable) creates a system that is prepared to accept new options, that could not be predicted at the time of creation.

This is the best user experience. Don’t define an architecture for your users, let your users define themselves. Take the minimum amount of information necessary. Plan for expansion in ways you cannot predict. Let users define when & how those expansions occur. Repeat.

Technology reflects life. Life reflects technology.

There’s also an updated link at the bottom regarding the SCOTUS decision on June 26, 2015, along with how NoSQL database architecture addresses many of the issue of the original article. 

[rubidium-riesling-blog]

There are various objections to expanding the conventional, up-tight, as-God-intended "one man, one woman" notion of marriage but by far the least plainly bigoted ones I am aware of are the bureaucratic ones.

To be blunt, the systems aren't set up to handle it. The paper forms have a space for the husband's name and a space for the wife's name. Married people carefully enter their details in block capitals and post the forms off to depressed paper-pushers who then type that information into software front-ends whose forms are laid out and named in precisely the same fashion. And then they hit "submit" and the information is filed away electronically in databases which simply keel over or belch integrity errors when presented with something so profound as a man and another man who love each other enough to want to file joint tax returns.

Speaking as a computery-type person, altering the paper forms is not my department. It's probably expensive and there are probably millions of existing incorrect forms which would need returning or recycling or burning instead of using. Or maybe it's simple. I don't know. The real question from my perspective is how you store a marriage in a computer.

Altering your database schema to accommodate gay marriage can be easy or difficult depending on how smart you were when you originally set up your system to accommodate heterosexuality only. Let's begin.

Note: By popular demand, this problem is now known as "Y2gay".