新闻 
资深IT人员告诉你,为什么DOGE总是闹笑话
资深IT人员告诉你,为什么DOGE总是闹笑话资深IT人员告诉你,为什么DOGE总是闹笑话
记得 2020 年大选时，网上盛传某个州选民数据库里很多选民生日是 1800 年 1 月 1 日或 1900 年 1 月 1 日。于是有人说，这还了得，200 多岁的人还在投票！
说实话，我当时一看就明白，这一定是一个派特别用途的特定数值。果然，后来听见 CNN 电台里解释说这是个占位符(placeholder)，说是用这个日子代表已经投过票的人。当时我也对人说，我猜是个特定值。但马上有人说，从来没见过设计数据库时，生日栏不输入生日信息，却派这样的用途。不可能！
我只能说，这样说话的人不懂得数据库前台与后台的区别。这种实践在数据库应用里非常普遍。你没听说过是因为你只看得见前台，而做后台的人不需要告诉你这些“肮脏”的东西。
没有人会在设计数据库的时候就决定把生日栏派这个用场。这样的“设计”都是慢慢演变出来的。任何企业或机构，业务范围或运作方式随时会发生变化，于是对数据库就会有新的要求。一个数据库投入应用后，结构不能随便改。即便现在数据库已经越来越机动灵活了，改变的空间也有限，这就必须在现有条件下发挥创造性来满足业务要求。
我不知道上面例子的真实情况是怎样的，但我可以从专业角度猜测。下面就是几种数据库应用中经常发生的只有在后台才看得见的“不寻常”现象（其中包括但不限于针对上面例子的情况）。
1）数据库后台有不止一个生日栏，分布在不同的表格里。
这就有了机动性，可以保留一个生日栏作为真正的生日，其他派别的用途。上面例子就很可能是这种情况，凡是已经投过票的，就在这个多余的生日栏输入特定的日子，如果这个选民再次来投票，系统就会拒绝。
别问我为什么会有一个以上生日栏。这个世界稀奇古怪的事情很多，包括数据库的设计或数据库里的数据。大概率是从不同地方数据迁移过来汇总的结果，为了某种原因——比如同一个人不同来源的数据给出不同的生日——不得不给两个、三个生日栏，把不同来源的生日存在不同地方，日后慢慢清理，最后全部输入一个地方。
2）有一种可能，以前对搬离本州或故世的选民，都是采用删除的做法。后来业务要求变了，需要保留记录，只是将这些人标为不能投票。
为了满足新的业务要求，做后台设计的人决定用生日栏来做标记，凡是搬离的选民，就把生日改为 1800 年 1 月 1 日；凡是去世的，就输入 1800 年 1 月 2 日；凡是犯罪被剥夺投票权的，生日一律是 1800 年 1 月 3 日……关键是选择一个“不可能”的日子，这样就不会与真实的日子混淆。
这里就再现了我前面说的非专业人员看不懂后台数据的情况。要从后台调出今年的合格选民，你必须知道选择条件，必须排除那些生日是特殊日子的人。不知道的人直接去后台看数据，就以为自己发现了惊人的秘密。事实上，那些选民是不会获得投票资格的。如果是从 app 里看，你根本不会看见不合格选民，因为被系统过滤掉了。在 app 上，可能只有有特别权限的人才能看见不合格选民。
3）也有可能，数据库原先的设计是，投票记录表格只记录最近一次选举的投票。系统也不保留历史投票记录，每次选举就抹去以前的记录，重新开始。但是，后来又要求保留所有投票记录。于是，名称为“最近一次选举投票记录”的那个表格里，一个选民会有很多记录。让事情更糟糕的是，那个表格没有投票日这一栏，也没有其他可以用作类似用途的内容，这样的话，要调出最近一次投票记录就必须通过与其他表格中的记录相连，甚至可能需要利用系统内在的“时间戳”(timestamp)才能调出正确的内容。当限制条件在另外的表格里时，仅仅看一个表格，就不可能知道这一笔记录是不是“有效”。至于需要利用系统时间戳的，这是“不可见”的东西，外行在后台绝对看不出名堂，相反还会“发现”，居然有那么多人在一次选举中多次投票！
数据库是个特别的东西
数据库有其特殊性，也有自己特殊的难度，特别是做系统的改朝换代。我做过好几个大型数据迁移项目，深知把数据从旧系统迁移到一个结构完全不同的新系统是一个非常挑战的工作。稍有不慎就会犯毁灭性的错误。
以显示员工名单为例，如果一个应用程序忘记考虑“在职与否”那个栏目，把不该包括的名单都显示了出来，只需要在程序里加一个条件就改正了。这样的错误，除了面子不好看，不会有大伤害。但如果是数据迁移把这一栏漏了，就再也没办法区分员工的在职状态了。
[物价飞涨的时候 这样省钱购物很爽]
好新闻没人评论怎么行，我来说几句
说实话，我当时一看就明白，这一定是一个派特别用途的特定数值。果然，后来听见 CNN 电台里解释说这是个占位符(placeholder)，说是用这个日子代表已经投过票的人。当时我也对人说，我猜是个特定值。但马上有人说，从来没见过设计数据库时，生日栏不输入生日信息，却派这样的用途。不可能！
我只能说，这样说话的人不懂得数据库前台与后台的区别。这种实践在数据库应用里非常普遍。你没听说过是因为你只看得见前台，而做后台的人不需要告诉你这些“肮脏”的东西。
没有人会在设计数据库的时候就决定把生日栏派这个用场。这样的“设计”都是慢慢演变出来的。任何企业或机构，业务范围或运作方式随时会发生变化，于是对数据库就会有新的要求。一个数据库投入应用后，结构不能随便改。即便现在数据库已经越来越机动灵活了，改变的空间也有限，这就必须在现有条件下发挥创造性来满足业务要求。
我不知道上面例子的真实情况是怎样的，但我可以从专业角度猜测。下面就是几种数据库应用中经常发生的只有在后台才看得见的“不寻常”现象（其中包括但不限于针对上面例子的情况）。
1）数据库后台有不止一个生日栏，分布在不同的表格里。
这就有了机动性，可以保留一个生日栏作为真正的生日，其他派别的用途。上面例子就很可能是这种情况，凡是已经投过票的，就在这个多余的生日栏输入特定的日子，如果这个选民再次来投票，系统就会拒绝。
别问我为什么会有一个以上生日栏。这个世界稀奇古怪的事情很多，包括数据库的设计或数据库里的数据。大概率是从不同地方数据迁移过来汇总的结果，为了某种原因——比如同一个人不同来源的数据给出不同的生日——不得不给两个、三个生日栏，把不同来源的生日存在不同地方，日后慢慢清理，最后全部输入一个地方。
2）有一种可能，以前对搬离本州或故世的选民，都是采用删除的做法。后来业务要求变了，需要保留记录，只是将这些人标为不能投票。
为了满足新的业务要求，做后台设计的人决定用生日栏来做标记，凡是搬离的选民，就把生日改为 1800 年 1 月 1 日；凡是去世的，就输入 1800 年 1 月 2 日；凡是犯罪被剥夺投票权的，生日一律是 1800 年 1 月 3 日……关键是选择一个“不可能”的日子，这样就不会与真实的日子混淆。
这里就再现了我前面说的非专业人员看不懂后台数据的情况。要从后台调出今年的合格选民，你必须知道选择条件，必须排除那些生日是特殊日子的人。不知道的人直接去后台看数据，就以为自己发现了惊人的秘密。事实上，那些选民是不会获得投票资格的。如果是从 app 里看，你根本不会看见不合格选民，因为被系统过滤掉了。在 app 上，可能只有有特别权限的人才能看见不合格选民。
3）也有可能，数据库原先的设计是，投票记录表格只记录最近一次选举的投票。系统也不保留历史投票记录，每次选举就抹去以前的记录，重新开始。但是，后来又要求保留所有投票记录。于是，名称为“最近一次选举投票记录”的那个表格里，一个选民会有很多记录。让事情更糟糕的是，那个表格没有投票日这一栏，也没有其他可以用作类似用途的内容，这样的话，要调出最近一次投票记录就必须通过与其他表格中的记录相连，甚至可能需要利用系统内在的“时间戳”(timestamp)才能调出正确的内容。当限制条件在另外的表格里时，仅仅看一个表格，就不可能知道这一笔记录是不是“有效”。至于需要利用系统时间戳的，这是“不可见”的东西，外行在后台绝对看不出名堂，相反还会“发现”，居然有那么多人在一次选举中多次投票！
数据库是个特别的东西
数据库有其特殊性，也有自己特殊的难度，特别是做系统的改朝换代。我做过好几个大型数据迁移项目，深知把数据从旧系统迁移到一个结构完全不同的新系统是一个非常挑战的工作。稍有不慎就会犯毁灭性的错误。
以显示员工名单为例，如果一个应用程序忘记考虑“在职与否”那个栏目，把不该包括的名单都显示了出来，只需要在程序里加一个条件就改正了。这样的错误，除了面子不好看，不会有大伤害。但如果是数据迁移把这一栏漏了，就再也没办法区分员工的在职状态了。
[物价飞涨的时候 这样省钱购物很爽]
| 分享: |
| 注： | 在此页阅读全文 |
推荐: