我的应用程序包含一个包含大量外键的数据库。
插入的大量数据来自用户。
我只是想知道：在插入或插入之前对用户输入运行验证是否更好？只是编写错误捕获代码？
是否有性能/风格/安全方面的好处？
对我的膝盖反射似乎是两者兼而有之，但如果只做其中一个，那么之前进行验证似乎是一个更安全的选择。
答案 0 :(得分：4)
这是一个很好的问题 - 在我看来，使用对象关系映射器的好处之一。
通常，数据库提供的关系工具都是关于保护数据有效性 - “客户”必须具有“客户经理”关系，“user_name”可能不为空，“user_id”必须是唯一的等等。
这些工具对于验证用户输入数据库的数据是必要的，但还不够。
您的前端/中间层代码有自己的规则 - 通常不以关系术语表示;在大多数现代开发语言中，它们涉及对象以及对象或其属性之间的关系 - 例如，电话号码必须包含数字，名称必须以大写字母开头。
我假设您的用户不通过SQL与数据库交互 - 您已经构建了某种用户界面，允许他们查找关联（从而填充外键）。
在这种情况下，我首选的架构是：
答案 1 :(得分：0)
我认为这不应该是一个问题。正如你的建议，我总是这两个都做。至于优点和缺点，我会说我认为在生命周期的早期找到用户输入问题并以用户友好的方式处理它们更容易，而不是等到数据库抛出错误。但是，如果您的验证没有捕获所有内容，或者如果存在与用户输入无关的数据库错误，则在某些时候捕获错误仍然很重要。
答案 2 :(得分：0)
无论如何，你都需要陷入错误。谁知道会发生什么？ SQL超时？没有多少数据验证可以帮助解决这类问题。
像大多数问题一样，它们是最便宜的早期捕获;不要让用户在将数据发送到服务器之前输入无效数据/验证数据。本身不是业务逻辑，但该日期不包含字母字符等。
在中间层，我仍然会验证输入。另一位开发人员可以在不审查输入的情况下调用您的业务逻辑。我更喜欢这个领域的业务逻辑，因为它比在存储过程中创建逻辑更容易编写和调试。
在数据库上，当规则是绝对的时，我更喜欢约束，例如你没有没有用户ID的内部用户;原因是为了防止其他开发人员编写可以执行不应该允许的操作的脚本。