同性恋结婚及数据库工程.doc

同性恋结婚与数据库工程 ? ? ? ? ~下面将要讲一位可敬的数据库工程师发挥他丰富想象力，践踏法律，并凭借高瞻远瞩的锐利眼光跨越伦理底线的事。其中信息学的观点值得学习借鉴，啊...我说只有信息学....向这位作者对SQL的贡献致敬。 ~下文字仅表示原作者(qntm.org)观点，不代表本人意见。 ? ? ? ? 一夫一妻的婚姻传统由来已久，人们一直奉行不悖，对此没有丁点疑问，因此某些标新立异的做法得不到声援。此外最大的障碍不是法律，而是这些新品种的结婚，政府的信息系统处理不了。 结婚登记时需要在表格上写下自己和对方的名字，纸质文件其实并没有强制一男一女（附申请结婚登记声明书-供参考）。但是如果两位男的提交的这样一个表格，进行信息录入时系统会报错。由此看来，国家运行所需的规则实际上是写在计算机软件而不是法律法规中。假设政府发布了提高消费税的通知，只有在修改了税金计算程序中的算式之后，新的政策才能实施。所以，为了适应同性恋婚姻，要考虑变更民政部门关于户口的相关数据库。 使现有一夫一妻的户口数据库记录同性结婚的数据，要进行一些结构上的调整，好了，开始！ ? ? ? ? 一 首先从早已被现代人类抛弃，极其落后的技术开始，使用两张表： [男性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[其妻]（是引用[女性居民].[ID]的外键，未婚则为空值NULL） [女性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[其夫]（是引用[男性居民].[ID]的外键，未婚则为空值NULL） 这样的表简单易懂，方便查询，使用JOIN即可以直接将夫妻同时列出，但会造成数据的矛盾。查询到ID:45男性居民其妻是ID:699的女性居民，在女性居民表中查询ID699发现第五列写的其夫ID是1078，这明显会造成歧义。检查输入数据的程序把关不严就会出现很多类似的误会。 ? ? ? ? 二 稍微改进一下： [男性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[其妻]（是引用[女性居民].[ID]的外键，未婚则为空值NULL） [女性居民] ----[ID] ----[姓] ----[名] ----[生日] 不会造成歧义了，但是，造成了赤裸裸的性别歧视。此外，这两张表中没法记录结婚的一些关键细节，比如结婚日期。 ? ? ? ? 三 [男性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[其妻]（是引用[女性居民].[ID]的外键，未婚则为空值NULL） ----[结婚日期]（未婚则为空值NULL） [女性居民] ----[ID] ----[姓] ----[名] ----[生日] 再比如离婚日期之类的。 ? ? ? ? 四 [男性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[其妻]（是引用[女性居民].[ID]的外键，未婚则为空值） ----[结婚日期]（未婚则为空值） ----[离婚日期]（未婚或未曾离婚则为空值） [女性居民] ----[ID] ----[姓] ----[名] ----[生日] ?还有比如结婚地点什么的，见证人什么的......这些不能全部记录在男性居民表中，应该存储在单独的表中。 ? ? ? ? 五 ?[男性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[婚姻]（外键，引用[婚姻].[ID]，未婚则为空值） [女性居民] ----[ID] ----[姓] ----[名] ----[生日] ----[婚姻]（外键，引用[婚姻].[ID]，未婚则为空值） [婚姻] ----[ID] ----[结婚日期] ----[离婚日期]（未曾离婚则为空值） 这样，看起来有些关系型数据库的样子了。但是可能存在的大量空值还是不像样。 ? ? ? ? 六 ?[男性居民] ----[ID] ----[姓] ----[名] ----[生日] [女性居民] ----[ID] ----[姓] ----[名] ----[生日] [婚姻] ----[ID] ----[男方ID]（外键，引用[男性居民].[ID]） ----[女方ID]（外键，引用[女性居民].[ID]） ----[结婚日期] ----[离婚日期]（未曾离婚则为空值） 如此一来，数据库看起来美观得多并且不存在性别歧视之类的问题。但是看这[男性居民]和[女性居民]两张表有相同的四列，却还分成两个表，这应该是一种浪费。一个ID可以是一个男性居民，同时是另一个女性居民，这个地方也会出问题。毕竟世人认为男性不会变成女性，女性不会变成男性，结婚双方的ID必定一个在[男性