这个问题的目标是在Doctrine 2中建模有限的可用性。我确信这已经在这里讨论过，因为它似乎很基本，但我找不到任何最佳实践。可能是limit / restrict / max / ...是糟糕的搜索词，因为它们都意味着db世界中的其他东西： - ）。
假设一个典型的在线商店应用程序允许多个用户购买某种物品（同时）。其中一些项目的可用性有限（先到先得）。因此，在尝试签出/确认订单时，两个用户可能处于并发状态。必须赢得比赛的速度越快，其他订单甚至不应被处理（插入数据库中）。
实体/表格可能如下所示：
项
+----+-----+---------------+---------+
| id | ... | max_available | version |
+----+-----|---------------|---------+
| 7 | | 4 | 2 |
| 8 | | 1 | 0 |
订单
+----+---------+----------+
| id | item_id | quantity |
+----+---------+----------+
| 1 | 7 | 2 |
| 1 | 7 | 1 |
在这种情况下：数量为1的第8项的另一个订单有效。必须防止数量为2的第7项的另一个订单，因为这将是另一个可用的订单。
应用程序使用Doctrine 2 ORM，db将是MySQL。系统可以耦合到db类型，但如果有合理的db不可知方式，那当然更好。
对此进行建模的最佳方式是什么？
事务和数据库级别的锁定（db需要支持这个）？锁定ORM级别（整数版本字段）？或者是否应该（另外）安装了确保数据库级数据完整性的触发器？
旁注：约束是否应该是设计可选的，还是它们可以成为业务逻辑的一部分？换句话说：在正常情况下测试不受限制并让测试失败是不好的做法 - 例如通过在更新/插入上具有（并发安全）触发器，如果项目不再可用，则取消请求？ （这只适用于某些数据库类型和InnoDB作为MySQL的引擎......）