后端是否应该在 SQL 查询之前执行一致性检查？

Question

语境通过一致性检查，我的意思是消除肯定不会返回任何内容的查询。例如：考虑表boxes，其中可用列之一是color CHAR(6)；用户通过与前端的交互发送该字符串'abcdefg'以针对列进行查询；color然后，后端将SELECT * FROM boxes WHERE color = ?使用上面提到的相同字符串执行类似于 的查询；至少在我的 PostgreSQL 安装中，我可以执行这个查询，即使知道它永远不会返回任何内容（长度为'abcdefg'7）。目前，前端和后端都会在从数据库访问数据之前执行一致性检查（以避免不必要的调用）。事实上，前端的设计就是为了禁止用户请求无效的查询。但假设没有进行这些检查，尤其是在后端，这对应用程序有多重要？问题PostgreSQL 如何处理这些查询，它是否有任何类型的算法在执行此类查询时立即不返回任何内容？或者不调用数据库而只向用户发送类似not found或 的内容会更好吗invalid request？进一步的背景我们已经清理了从前端接口获取的所有输入，因此这不是关于执行这些检查后获得的安全性可能带来的好处/坏处的问题。我们后端使用的语言是 Go，我相信它在定期执行这些检查（即在大多数 HTTP 请求上）时没有问题。PS：我知道你可以在 PostgreSQL 中将十六进制转换为整数，这只是一个假设的问题，我用它来简化对问题的理解（我希望它能做到）。

Answer 1

我会在前端或后端执行此类检查，只要最方便，但不会同时在两者中执行。第二道防线是数据库，两道就足够了。

在应用程序中找到不正确的数据是一件好事，但不要太过分：如果您在数据库和应用程序中硬编码诸如最大字符串长度之类的内容，则必须在两个地方修改该限制无论何时，代码冗余都是一件坏事。

仍然理智的东西在很大程度上取决于品味和意见：我认为检查应用程序中的长度限制而不是依赖数据库中的错误是很好的，但我认为用猜测的复杂逻辑给应用程序增加负担是值得怀疑的SQL 语句的结果。

重要的是对数据库中所有重要的一致性检查进行建模，只要捕获并妥善处理数据库错误，就不会出现任何问题。除此之外的一切都可以被视为性能调整，并且只有在它提供了明显的好处时才应该进行。