试想一下,你用整数格式建立了一个全部是邮编的表格。这个表是十分高效的,它执行的规则也很好。突然一次,有人上传了一个使用了连字符的九位数邮编。或者还有可能,你得到了一位来自加拿大客户的信件,上面写有邮政编码。
这时,一切都乱了。老板要求网站要在几小时内恢复正常工作。然而,现在已经没有时间来重建数据库。程序员可以做什么?也许,可以使用黑客手段把加拿大邮政编码由base64的数字格式改为base 10格式?或者设置一个使用转义编码的辅助表格,用来说明真正的邮政编码或者其他?谁知道呢?到处都有黑客,他们都是危险的。但你没有时间来搞定它。
MySQL的关联规则让每个人都诚实和谨慎,但它能强制我们避开易受攻击和欺骗的麻烦。
是的,一个可靠的、得到良好支持的MySQL分支,可以带来竞争和选择,但是它也引起困惑和混乱。更糟糕的是,一个称为MariaDB的MySQL分支,由Monty Widenius维护着。他同样也在参与编写MySQL。那么,MariaDB是真正独立的值得我们拥护的吗?或者它是MySQL?我们是否应该坚持使用由创建原始MySQL数据库的组织运营的核心代码?或者我们应该加入那些被认为更聪明的,往往很酷的背叛者?
还有,我们应当如何获得关于兼容性的信息?一方面,我们被确信MariaDB和MySQL十分地相似。另一方面,我们要相信有差异——不然为什么大家都在争论它?也许它们在性能和我们查询的范围内,在两个阵营中工作方式相同?但也许他们不同-或者将来会不同。
MySQL不是事实上的同一的数据库;它由几个数据库组成,它们的大多数细节都被统一的表面所掩盖。在开始的时候,有一个MyISAM引擎,它很快但是在前后一致上不能做到完备。有时候你需要速度并且可以接受不一致的结果时是很好的。
当人们需要更多时,具备完整事务支持的InnoDB出现了。但这还不够。现在,它可能有20种存储引擎的选择——这足以使一个数据库管理员疯狂。当然,有些时候在不同的存储引擎之间切换而不必重写你的SQL是很好的,但是切换后总会带来混乱。这个表格我选择的引擎是 MyISAM 还是 innoDB 呢?或者,我决定输出的数据是CSV格式的吗?
评论删除后,数据将无法恢复
评论(48)
引用来自“oreax”的评论
这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体,将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快,并且服务器也不会耗尽内存。--------------------------------
落伍了,原来现在要的不是规范,而是能用就行
引用来自“oreax”的评论
这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体,将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快,并且服务器也不会耗尽内存。--------------------------------
落伍了,原来现在要的不是规范,而是能用就行
引用来自“Havencode”的评论
最烦就是什么都要扯上Json。除了Json你就不会用点别的?!引用来自“五杀联盟”的评论
加1引用来自“fengyqf”的评论
+2引用来自“车开源”的评论
+1024引用来自“Havencode”的评论
最烦就是什么都要扯上Json。除了Json你就不会用点别的?!引用来自“五杀联盟”的评论
加1引用来自“fengyqf”的评论
+2