我正在设计我的第一个电子商务模式。我已经阅读了一段时间的主题，并且对 anorder_line_item和 a之间的关系感到有些困惑product
一个product可以被购买。它有各种细节，但最重要的是unit_price。
Anorder_line_item有一个外键，指向product_id购买的、quantity购买的和unit_price客户购买产品的时间点。
我读过的大部分内容都说应该明确添加unit_priceon order_line_item（即不通过 引用product_id）。有道理，因为商店将来可能会改变价格，这会弄乱订单报告、跟踪、完整性等。
我不明白的是，为什么直接将unit_price值保存到order_line_item?
创建一个记录unit_pricea 更改的审计/历史表不是更好product吗？
当order_line_item被创建，所述的外键product_audit表，并将该价格可以从那里检索（通过引用）。
在我看来，使用这种方法有很多好处（减少重复的数据、价格变化历史等），那么为什么不更频繁地使用它呢？我还没有遇到使用这种方法的电子商务模式的例子，我错过了什么吗？
UDPATE：我的问题似乎与Slowly Changed Dimension 相关。我仍然感到困惑，因为缓慢变化的维度与数据仓库和 OLAP 相关。那么，缓慢变化的维度类型可以应用于我的主要业务事务流程数据库 (OLTP) 吗？我想知道我是否混合了很多概念，非常感谢一些指导。
我正在创建一个 RESTful API。我正在努力决定围绕我的资源设计我的数据库表的最佳方式。
最初，我认为每个资源一个表是一个很好的方法，但我现在担心这会导致你在资源链的下游形成指数级更大的表。
例如，假设我有三个资源 - 用户、客户、销售。用户是我的 api 的订阅者，客户是用户的客户，销售是每个客户对用户帐户的购买。
一个销售资源的访问方式如下
GET /users/{userID}/clients/{clientID}/sales/{salesID}
因此，如果有 10 个用户，每个用户有 10 个客户，并且每个客户有 10 个销售，那么表的大小会随着资源链越往下而越大。
我相当有信心 SQL 可以处理大表，但我不确定读取和写入将如何减慢速度。上面的例子可能没有说明它，但我的 api 将有越来越多的写入和读取我们走的资源链越远。因此，我的数据库中最大的表将比较小的表被读取和写入更多次。
在运行查询之前连接表也是必要的。原因是我允许每个用户有一个同名的客户端。为避免获取错误的客户端数据，用户表和客户端表由 {userID} 连接。销售也是如此。加入大表并运行读写会进一步减慢速度吗？
我有两个 SQL 表：用户和客户。
users 表中的每一行在clients 表中都有一组clients，由users 表id字段和clients 表user_id字段链接。
用户表有一个username唯一的字段。
客户表有一个user_id字段 ANDclientname字段，它们一起是唯一的（即clientnames可以存在多次，但必须有不同的user_ids）
我的问题是：如何添加强制username用户表中的clientname字段和客户表中的字段之间的唯一性的规则？甚至有可能吗？
即 nousername可以与 a 相同clientname，noclientname可以与 a 相同username。