PHP / MYSQL - 如何在应用程序中处理数据库级约束

Question

我已经查看并查看了相关问题，在应用程序与本机数据库约束中处理数据库约束的一般问题，但我的问题更加尖锐和具体，关于如何处理用PHP编写的应用程序逻辑中的本机mysql约束。

在其他语言/数据库包装器中（例如ADO.NET），您将数据库交互放在try / catch中，并抛出一个正确的异常，这是php的情况吗？

另外，使用严格的ORM是否否定了数据库级约束的需要？

Answer 1

  

在其他语言/数据库包装器中，   （例如ADO.NET）你放置你的   数据库内的交互   尝试/捕获并抛出一个正确的   例外，这是php的情况吗？

它与PDO有关......而且我认为Mysqli但我在几年内没有使用它，所以我可能错了。但是它只抛出一个PDOException ......没有特定的异常类型可以说'重复键'或'非空'...你必须从异常的消息/代码中解析那些。

  

另外，是否使用严格的ORM   否定对数据库级别的需求   约束

我会说不。一般来说，如果可以的话，让db处理这个问题会更好，因为如果用PHP模拟它会带来更多的开销。

Answer 2

try / catch块的神话是程序员将生成令人惊讶的强大代码，并且实际上能够从失败的数据库查询中恢复。但是从db错误中恢复的能力取决于首先出现的错误类型 - 如果存在sql语法错误，该代码是来自用户输入查询，还是来自某个生成该错误的子例程查询？如果它来自代码，而不是用户，那么再次调用代码将再次产生相同的错误，因此使用try / catch块从一开始就注定要失败，查询不会继续运行。这通常是从Web服务器上运行的PHP脚本获得的代码类型，运行查询，失败，升级失败并放弃。另一方面，如果您正在用PHP编写交互式应用程序，并且需要正确处理db错误，例如遗传算法试图通过随机变异来演变有效的SQL语句（一个非常奇怪的例子，但无论如何），那么你会从try / catch块获得一些好处。

这也适用于数据库级约束。如果你有一些长时间运行的应用程序需要优雅地处理约束违规，那么你必须自己构建这种健壮性。但我想很少有人以这种方式使用PHP，99％的php用于转储网页，各种包装和ORM在他们的设计中反映了这一点。使用.NET构建需要错误恢复逻辑的独立应用程序的可能性要大得多。

然后返回到原始问题的变体，何时使用或为何使用数据库约束？当您具有高度动态的数据库结构时，它们最有用，其中表之间的关系在编译时是未知的，即当创建或修改新表作为应用程序本身的一部分时丢弃。您可能希望将其用于大量数据仓库，数据挖掘或字符串理论。