Mysql 出于安全考虑，对于库存系统的单个事务，将多行添加到事务表（每单位1行）的DB设计是否合理？

编辑/更新问题：

以下问题特别适用于库存应用程序

具体来说，该应用程序支持大量数千个位置，每个位置都有足够数量的产品，可以放在典型的车身车间的货架上。但是，系统可能会扩展以支持更大的仓库

我个人不理解为什么库存应用程序会与任何其他大型数据库应用程序有任何不同，但我在下面提到的程序员告诉我，根据他的经验，库存应用程序通常会使用本问题中讨论的设计

程序员还声明，所述设计特别适用于盗窃率高的应用；i、 e.在汽车车身店工作的人倾向于在货架上到处乱扔一些产品。即使在这种情况下，我也不明白为什么在用户界面保持不变的情况下，按照本问题所述设计后端系统会保证所示的设计

因此，下面问题的附录是下面讨论的设计是否特别适用于库存应用，在这种应用中，货架存货商在地板上的盗窃率很高

我与另一位程序员有着显著的不同意见，他为从头开始构建的库存数据库提出了一个根本不同的模式设计方案

< P>我想知道所提出的模式概念是否是一个标准设计，和/或它是否应该被认为是设计的选择，或者至少与其他可能的设计方案相符合，对于库存系统。 库存系统在概念上相当简单，主要由油漆和其他液体以及一些固体零件组成，这些零件存放在全国各地的车身商店货架上。这些项目由卡车交付，作为库存的补充输入系统，然后从库存中移除，以完成维修订单

程序员提出了一种设计方案，在该方案中，记录每次向商店库存添加或从中删除任何库存项目的交易表中，为每个单独的交易向表中添加了多行，交易中每单位数量添加一行

例如，如果卡车司机向车间交付10罐特定的蓝色油漆，并且这10罐油漆通过单个事务输入到系统中，则仍会向事务表添加10行，每罐油漆一行；除了自动递增的主键外，每一行都是完全相同的

具体而言：

CREATE TABLE IF NOT EXISTS `transactions` (
  `transaction_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `part_id` int(10) unsigned, -- FK. parts.part_id
  `user_id` int(10) unsigned, -- FK: users.user_id
  `action` enum('ADD','REMOVE'),
  `action_date` datetime,
  PRIMARY KEY (`transaction_id`)
);

特别要注意的是，在一次交易中添加了10罐油漆的情况下，交易表没有数量列。相反，对于这个事务，将有10行添加到此表中，所有行都设置了ADD标志

从易用性、数据大小、编程复杂性和性能的角度来看，我确信这种设计显然不如一个具有数量列且每个事务只有一行的设计好。在本例中，将只添加一行，数量列将设置为10

程序员给出的理由是针对各种恶意用户的安全性

他同意，除了其他典型的安全预防措施外，这种设计是一个相对较小的附加安全层，但他指出了每单位数量一行方法的各种潜在安全特性

特别是，更容易利用细粒度数据库权限来防止恶意用户入侵系统或在某种程度上访问系统的内部员工删除整行或进行批量行更改，这是为了防止恶意用户修改单行数据中的单个数量字段

换句话说，这个概念是写一次，一成不变，每一项写一行

我确实指出，write once，freeze in stone的概念也适用于带有quantity列的方法，但在后一种情况下，恶意用户重写历史所需做的就是修改单行中的单个字段以进行重大更改；然而，对上述拟议系统进行重大更改的唯一方法是删除多行或批量更改行

我注意到，从编程的角度来看，这两种设计是完全不同的。在某种程度上，处理每事务多行方法的代码将比处理每事务单行方法的代码更复杂

< p> 这位程序员还指出，使用他建议的方法增加了代码的复杂性，这一事实将减少未来程序员犯错误的可能性，从而导致数据中出现严重的不准确。作为回应，我指出相反的情况也成立：程序员可以更容易地利用其更复杂的设计来弥补一个错误，而这些设计可能会在许多事务中被检测不到，从而导致数据中出现潜在的同样严重的不准确

在我看来，无论以何种方式进行切割、切片或切割，都会有明显更复杂的编码逻辑来处理此拟议设计的编程接口，并且在性能和扩展方面会有明显更大的开销。换句话说，这是一种根本不同的数据库设计方法，其唯一理由是安全性

我的感觉是，大约在20年前，这些安全性论据的应用更为广泛，当时web应用程序和服务器的整体安全性水平远不如今天。我感觉只有1%的安全性提高，而程序员的时间开销和服务器扩展成本只有30%

我的问题是：这个系统是否应该认真考虑这里描述的设计？或者每个事务只有一行和一个quantity列的模式设计显然是更好的选择吗

与顶部问题编辑相关的其他评论：

考虑到应用程序的用户界面保持不变，我不理解本问题中讨论的设计如何有助于防止员工在货架上储存和移除物品时对系统进行游戏

我是否遗漏了有关安全设计的一个重要细节？在这个问题中讨论的后端设计是否会以某种方式使货架存货商更难与系统博弈

或者，有权访问具有不同用户权限级别的后端系统的系统管理员也会有诱因以保证给定设计方法的方式对系统进行游戏，是否存在一些商业原因

---

我对这件事真是摸不着头脑。

所以我可以去银行存我挣的每一美元，而不是一次把它们全部存起来，从而降低被抢劫的可能性？很有趣。50吨可储存为50000.000.000行，每行每1毫克。我们也可以考虑微克：50吨＝50.000 0.000 000行，每微克一个-安全性应该是1000倍更强。当客户问我为什么这个简单的报告永远运行？我会告诉他：我们必须统计十亿行，这是一个非常强大的安全性的代价。@kordirko数据库中的每个部分都有一个标准合理的度量单位，所以这是每行的基础。我仍然没有向客户澄清每笔交易的典型项目数量——我不相信客户对此非常确定，因为该系统将来可能会扩展到新的产品线。在这位程序员提出他所设计的系统之前，我并不太关心典型量的问题。油漆罐是当前主要的产品之一。值得注意的是，程序员告诉我，库存系统通常是这样设计的。多年来，我处理过许多复杂的数据库，我从未见过以这种方式设计的大型数据库，尽管我见过使用“一次写入，永久冻结”方法的数据库，但我过去没有专门处理过库存数据库，那么我该说谁呢？