数据库新手常犯的5个错误

发表于:2018-8-09 10:19

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:数据库开发

分享:
  刚做开发人员的时候,需要掌握的东西非常多。首先是编程语言本身,还有所有你用到的框架的的特定用法,之后(也可能是之前),前端开发的东西也会混进来,在开发过程中你还要考虑数据存在哪的问题。
  起初,由于你有太多东西需要迅速掌握,在应用设计的过程中,会倾向于把数据库放在后面考虑(大概因为它对用户的使用体验没什么影响)。结果就是在处理数据库的时候,会发现很多不好的实践。这里举几个例子。
  1. Storing images 储存图片
  数据库里不应该放图片。你可以做的事情并不代表你就应该去做。图片会占用数据库里相当大的空间,吃掉不必要的 IO 资源从而拖慢应用。这个错误最常出现的情况,就是新人将图片用 base64 编码,然后将其储存在很大的 text/blob 字段当中。
  更好的办法是直接将图片上传至像 Amazon S3 这样的云服务上,然后用数据库里用 text 字段储存图片的 URL。每次要加载一张图片的时候,只要把图片的 URL 输出到有效的 <img> 标签里就可以了。这会极大地提升网页的响应速度,对大规模 Web 应用非常有帮助。
  2. Limit/Offset
  分页在很多应用中都非常常见。从你开始学习 SQL,(你就该知道)最直接的分页方法就是先用 ORDER BY 对数据库的一些列进行排序,然后 LIMIT 返回的结果数,对除第一页外的每一页使用 OFFSET。这看起来很符合逻辑,直到你处理中等规模应用时才意识到:
  它对数据库施加的负载是非常痛苦的。
  它具有不确定性,记录应该随着用户翻页而改变。
  不幸的是:分页非常复杂,目前还没有一个万全之策。
  3. 用整数做 primary key
  在创建 primary key 的时候,几乎所有的 ORM(Object Relational Mapping 对象关系映射)的默认做法都是创建一个串行字段,它是按顺序自动生成的,然后你就可以用它(这些自动生成的数字)作为你的 primary key。在管理员看来,这是非常直观的,因为可以由用户 1 到 用户 2 这样依次查看。对大多数的应用来说,这种做法通常是不错的。但是随着这些整数 primary key 不断变大,你很快就会意识到处理他们会让人筋疲力尽。对于大规模系统,这是很不理想的处理方法。此外,你还会依赖生成这些 key 的那个系统,在你必须要扩大规模的时候,会非常痛苦。更好的解决办法是从一开始就利用好 UUID (Universally Unique Identifier 通用唯一识别码)的优势。
  (UUID)还有其它的好处,那就是它不会无形中暴露给用户(数据库中)有多少用户、列表、或是这些 key 所指代的任何东西。
  4. 新列中的默认值
  无论你做这个工作有多久,都不会一次就创建出一个完美的 schema。最好是将数据库 schema 视为一个持续演化的文档。不幸的是:向数据库中添加一列是件很容易的事,这也就意味着在添加列的时候把工作搞砸同样很容易。默认情况下,如果你新添加了一列,通常是允许有 NULL 值的。这个操作速度很快,但大多数应用实际上不太想让他们的数据里有 null 值,他们会想要设置默认值。
  如果你在表里添加设置了默认值的新列,会对这张表触发一次完全的重写。注意:这对应用中的任何(数据量)很大的表都非常不利。(正确的方法)恰恰相反,最好是先允许 null 值存在,这样操作就是即时的,接下来再设置默认值,再用后台进程去回溯更新数据。
  实际操作比我所说的要更复杂,幸好已经有一些便利的指南可以为我们提供帮助。
  5. 过度标准化
  开始学习数据库的标准化的时候,(标准化)感觉就像是很正确的事。你创建了一个 posts 的表,里面包含 authors,每篇文章(post)都属于一个条目(category),所以你又创建了一个 categories 的表,然后再创建一个把它们俩 join 在一起的表,post_categories。从根本上来说,这样做标准化也没什么原则上的错误,但是某种程度上,标准化的收益正在递减。
  在上述实例中,categories 可以简单地作为 post 里的一个 varchar 字段。标准化是件很有意义的工作,但是每次处理包含多对多关系的表时都要深思熟虑,想想你是不是真的需要在关系的两边都各用一个单独的表。
  修正:值得一提的是,欠标准化也是个问题。这里并不存在“一刀切”的解决方案。有时完全不做标准化和完全标准化也行得通。像 @fuzzychef 说的那样:“适度标准化,即金发姑娘原则(The goldilocks principle,意为适度的是最好的)”。
  总结
  在 Twitter 上问到这个问题的时候,我得到了很多非常棒的回应,但是这些回应五花八门。从“从不查看 ORM 生成的查询”这样的基本问题,到像事务隔离这样的进阶话题。有一点我并没提到,但是对于所有构建 app 的人来说都非常值得注意的一点就是索引。了解索引的工作原理,知道你需要创建什么样的索引,是获得良好的数据库性能的关键。除了用 Postgres 分析性能的实践步骤以外,还有很多关于索引的基础知识的文章。
  通常我会鼓励大家把数据库当做你工具箱中的另一个工具,而不是什么非学不可的恶魔。但我希望,以上的提示可以帮助初学者避免一些基本错误。

   上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号