数据库新手常犯的5个错误首先是编程语言本身，以及你使用的所有框架的具体用法。后面（或者可能之前），前端开发的东西也会混进去，在开发的过程中，你要考虑数据存在的地方。一开始，由于要快速掌握的东西太多，所以在应用程序设计过程中有把数据库放在次要位置的倾向（大概是因为它对用户体验影响不大）。结果，在处理数据库时会发现许多不良做法。这里有一些例子。1.存储图像图像数据库中不应存储图像。仅仅因为你可以做某事并不意味着你应该做。图像会占用数据库中的大量空间，消耗不必要的IO资源并降低应用程序的速度。此错误最常见的情况是新手使用base64编码图像并将它们存储在大文本/blob字段中。更好的方法是将图像直接上传到像AmazonS3这样的云服务，然后使用数据库中的文本字段来存储图像的URL。每次要加载图片时，只需将图片的URL输出到有效的![]()
标签中即可。这将大大提高网页的响应速度，这对于大型网络应用程序非常有帮助。2.Limit/Offset分页在很多应用中很常见。自从你开始学习SQL，（你应该知道）最直接的分页方式就是用ORDERBY对数据库的一些列进行排序，然后LIMIT返回的结果数，除***之外的每一页都使用OFFSET页。在您处理中型应用程序之前，这似乎是合乎逻辑的：它给数据库带来的负载是痛苦的。它是不确定的，记录应该随着用户翻页而改变。不幸的是：分页很复杂，没有一种放之四海而皆准的解决方案。3.使用整数作为主键。在创建主键的时候，几乎所有的ORM（ObjectRelationalMapping对象关系映射）默认方法都是创建一个序列字段，这个字段是按顺序自动生成的，然后你就可以用它（这些自动生成的数字）作为你的首要的关键。从管理员的角度来看，这是非常直观的，因为可以按顺序从用户1到用户2查看。对于大多数应用程序，这种方法通常很好。但是随着这些整数主键变得越来越大，您很快就会意识到处理它们可能会让人筋疲力尽。对于大型系统，这远非理想的方法。此外，您仍然依赖于生成这些密钥的系统，这在您必须扩展时可能会很痛苦。更好的解决方案是从一开始就利用UUID（通用唯一标识符）。(UUID)具有额外的好处，即不会无形地揭示有多少用户、列表或这些键所指的任何内容。4.新列中的默认值无论你从事这项工作多久，你都不会一下子创建出一个完美的模式。诀窍是将数据库模式视为不断发展的文档。不幸的是：向数据库中添加列很容易，这意味着在添加列时很容易搞砸。默认情况下，如果您添加一个新列，它通常允许NULL值。这个操作很快，但是大多数应用程序并不真的希望它们的数据中有空值，它们会想要设置默认值。如果您向设置了默认值的表添加新列，则会触发对表的完全重写。注意：这对于应用程序中的任何（数据量）大表来说都是非常糟糕的。（正确的方法）相反，最好的方法是先允许空值存在，这样操作是即时的，然后设置默认值，然后使用后台进程追溯更新数据。它比我所说的更复杂，但值得庆幸的是，有一些方便的指南可以提供帮助。5.过度规范化当我第一次开始学习数据库标准化时，我觉得这是正确的做法。您创建了一个帖子表，其中包含作者，每篇文章（帖子）都属于一个类别（category），因此您创建了一个类别表，然后创建了一个将它们连接在一起的表post_categories。从根本上说，这样标准化在原则上没有错，但在某种程度上，标准化是收益递减的。在上面的示例中，类别可以只是帖子中的一个varchar字段。标准化是一项很好的工作，但每次处理包含多对多关系的表时，请仔细考虑是否真的需要为关系的每一方创建一个单独的表。更正：值得一提的是，欠规范化也是一个问题。这里没有“一刀切”的解决方案。有时根本没有规范化和完全规范化工作。正如@fuzzychef所说：“适度标准化，Goldilocks原则（意思是适度最好）”。总结当我在Twitter上问这个问题时，我得到了很多很好的回应，但他们都是五花八门的。从“永远不要查看ORM生成的查询”等基本问题到事务隔离等更高级的主题。有一件事我没有提到，但对于任何构建应用程序的人来说值得注意的一件事是索引。了解索引的工作原理，并了解您需要创建哪些索引，是获得良好数据库性能的关键。除了使用Postgres分析性能的实用步骤外，还有许多关于索引基础知识的文章。总的来说，我会鼓励每个人都将数据库视为工具箱中的另一个工具，而不是必须学习的恶魔。但我希望以上提示可以帮助初学者避免一些基本错误。
