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

创新互联是一家以成都网站建设公司、网页设计、品牌设计、软件运维、网站推广、小程序App开发等移动开发为一体互联网公司。已累计为成都护栏打桩机等众行业中小客户提供优质的互联网建站和软件开发服务。

刚做开发人员的时候，需要掌握的东西非常多。首先是编程语言本身，还有所有你用到的框架的的特定用法，之后(也可能是之前)，前端开发的东西也会混进来，在开发过程中你还要考虑数据存在哪的问题。

起初，由于你有太多东西需要迅速掌握，在应用设计的过程中，会倾向于把数据库放在后面考虑(大概因为它对用户的使用体验没什么影响)。结果就是在处理数据库的时候，会发现很多不好的实践。这里举几个例子。

1. Storing images 储存图片

数据库里不应该放图片。你可以做的事情并不代表你就应该去做。图片会占用数据库里相当大的空间，吃掉不必要的 IO 资源从而拖慢应用。这个错误最常出现的情况，就是新人将图片用 base64 编码，然后将其储存在很大的 text/blob 字段当中。

更好的办法是直接将图片上传至像 Amazon S3 这样的云服务上，然后用数据库里用 text 字段储存图片的 URL。每次要加载一张图片的时候，只要把图片的 URL 输出到有效的 标签里就可以了。这会极大地提升网页的响应速度，对大规模 Web 应用非常有帮助。

2. Limit/Offset

分页在很多应用中都非常常见。从你开始学习 SQL，(你就该知道)最直接的分页方法就是先用 ORDER BY 对数据库的一些列进行排序，然后 LIMIT 返回的结果数，对除***页外的每一页使用 OFFSET。这看起来很符合逻辑，直到你处理中等规模应用时才意识到：

1. 它对数据库施加的负载是非常痛苦的。
2. 它具有不确定性，记录应该随着用户翻页而改变。

不幸的是：分页非常复杂，目前还没有一个万全之策。

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 分析性能的实践步骤以外，还有很多关于索引的基础知识的文章。

通常我会鼓励大家把数据库当做你工具箱中的另一个工具，而不是什么非学不可的恶魔。但我希望，以上的提示可以帮助初学者避免一些基本错误。

分享标题：数据库新手常犯的5个错误
网址分享：http://www.shufengxianlan.com/qtweb/news34/549684.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联