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