刚做开发人员的时候，需要掌握的东西非常多。首先是编程语言本身，还有所有你用到的框架的的特定用法，之后(也可能是之前)，前端开发的东西也会混进来，在开发过程中你还要考虑数据存在哪的问题。
起初，由于你有太多东西需要迅速掌握，在应用设计的过程中，会倾向于把数据库放在后面考虑(大概因为它对用户的使用体验没什么影响)。结果就是在处理数据库的时候，会发现很多不好的实践。这里举几个例子。
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 分析性能的实践步骤以外，还有很多关于索引的基础知识的文章。
通常我会鼓励大家把数据库当做你工具箱中的另一个工具，而不是什么非学不可的恶魔。但我希望，以上的提示可以帮助初学者避免一些基本错误。
原文地址：https://www.cnblogs.com/syncnavigator/p/10198345.html