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

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

2年前关闭。




Improve this question




语境

通过一致性检查，我的意思是消除肯定不会返回任何内容的查询。

例如:

考虑表boxes ，其中可用列之一是 color CHAR(6) ;

用户发送此字符串 'abcdefg'要针对列 color 进行查询通过他与前端的交互；

然后，后端将执行类似于 SELECT * FROM boxes WHERE color = ? 的查询。 ，使用上述相同的字符串；

至少在我的 PostgreSQL 安装中，我可以执行这个查询，即使知道它永远不会返回任何东西( 'abcdefg' 的长度是 7)。

目前，前端和后端都在从我们的数据库访问数据之前执行一致性检查(以避免不必要的调用)。

事实上，前端旨在禁止用户请求无效查询。但是假设这些检查没有发生，特别是在后端，这对应用程序有多重要？

问题

PostgreSQL 如何处理这些查询，是否有任何类型的算法在执行此类查询时立即不返回任何内容？或者最好不要调用数据库，而是向用户发送类似 not found 的信息？或 invalid request ?

进一步的背景

我们已经对从前端接口(interface)获取的所有输入进行了清理，因此这不是关于执行这些检查后获得的安全性可能带来的好处/坏处的问题。

我们后端使用的语言是 Go，我相信它在定期执行这些检查时没有问题(即在大多数 HTTP 请求上)。

PS.:我知道您可以在 PostgreSQL 中将十六进制转换为整数，这只是一个假设问题，我用来简化对问题的理解(我希望它确实如此)。

Answer 1

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

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

什么仍然理智在很大程度上取决于品味和意见:我认为检查应用程序中的长度限制而不是依赖于数据库中的错误是可以的，但我认为用复杂的逻辑来猜测应用程序是有问题的SQL 语句的结果。

重要的是在数据库中对所有重要的一致性检查进行建模，然后只要您捕获并优雅地处理数据库错误，就不会出错。除此之外的一切都可以被认为是性能调整，并且只有在它提供了明显的好处时才应该这样做。