价格数据建模

Question

问题

我现在有一个产品数据库。下面是一个快速模式：

表bdProduct

|   IDBDProduct |
|   Code        |
|   Description |
|   DCreated    |
|   UCreated    |
|   DModified   |
|   UModified   |

我现在到了我想要储存价格的时候，在那里我有一些问题，我预测最好的方式。

最终，我很肯定我们将走向世界，这取决于我将在哪里销售我的应用程序，这意味着我可能有CAN美元(开始)，然后美元，欧元欧洲，等等。

储存这些信息的最好方法是什么？我已经想过：

| CANPrice |
| USDPrice |
| EURPrice |

我不知道为什么，但我觉得这不是个好办法。关于信息，过去三年我一直在使用该系统(CAN/美元/EURPrice)，我们一直在努力解决添加新类型的问题。

这是我已经收集到的

1. 把价格储存在另一张桌子上(我认为那是最好的方式?) 有一个bdProductPrice，可以节省价格和额外的信息 ( idAuto \x{e76f}\x{e76f}.| 其中我将存储IDProduct，它的价格和价格类型(它是CAN /美元/欧元) 我不喜欢这个选项的地方是，每次阅读产品时，我都要进行另一次查询才能得到它的价格。
2. 在当前数据库中添加价格 我不太喜欢这个选择。我觉得这会对我的数据库造成很大影响。我们失去了产品价格的历史，就像谁做了修改一样。
3. 你还有什么建议吗？ 好了，我很高兴听到你的消息，你试过，用过什么.什么对你最有效？

边问题

我问了关于价格的问题，但是我对翻译的数据也有同样的问题，例如，我会有一个英文的productDescription，但是我也会有一个法国的客户，所以，也许我应该把bdProductPrice转换成一个bdProductExtension，在这个bdProductExtension中存储我想给我的产品的信息类型？

Answer 1

根据你想要达到的目标，不同的方法是可能的。

我的建议：

• prices ：试着了解您想要提供多少种货币，如果它们是<10的话，然后在产品表中添加包含价格的列。您将在那里存储当前的价格。在第二张表中，您可以存储价格的历史变化。因此，当您需要显示当前价格时，您可以在不添加其他连接的情况下使用它。如果有具体的需要，历史价值就会存在。如果您有超过10种价格，或者您不喜欢多列的解决方案，您可以将价格保存在一个单独的表中，如下所示： 表Product_Prices IDBDProduct IDCurrency Start_date End_date

与End_date类似的31-DEC-9999作为当前值(对于获取当前价格也很有用)。

• Descriptions：通常是带有文本或甚至html标记的字段。就像价格一样，你可以采用相同的方法，把它们放在Product中，或者将它们分开，只在需要的时候使用它们。您甚至可以有简短的描述和长的描述，第一个在Product中，后者在Product_Description表中。如果不是经常需要的话，我宁愿把描述分开。

无论如何，在一天结束时，您需要将这些信息存储在某个地方。您可以尝试限制应用程序前端的复杂性，为您的商店的Price/Language组合创建视图(也可能是包含所有产品数据的扩展版本)。

 Product_UK     - basic product info, GBP_Price, English Short Description
 Product_FR:    - basic product info, EUR_Price, French Short  Description
 Product_CAN_EN - basic product info, CAD_Price, French Short Description
 Product_CAN_FR - basic product info, CAD_Price, French Short Description
(Product_UK_Ext - all product info, GBP_Price, English Short and Long Description)

最后一件事，我在过去看到的，通常你在处理产品，价格和描述时没有性能问题。零售应用程序的大量数据位于sales/transactions表中，获取产品描述的附加连接不会损害数据库(但这只是SQL而不是science :)。

Answer 2

也许我遗漏了一些东西，但是为什么不只是在表中添加一列(也许是CURRENCY_TYPE )，并有另一个表用于引用完整性，这样用户就不能为同一种货币(CAN、加拿大元等)放置多个值，并且可以存储您想要的有关该货币的任何信息。

对于有关货币的任何信息，仍然需要对参考表进行连接，但是在基表上，您将得到价格和它的货币类型。

Answer 3

在我看来，数据库是存储信息的地方，将语义信息(比自己的数据库模式提供的更远)移动到数据库通常是一种不需要多次的开销。

除非同一商店需要使用不同货币的价格，否则将此信息转移到数据库是没有意义的。任何购物者通常都希望所有的价格使用相同的货币。

因此，我只会在数据库中存储价格(正如您最初所认为的那样)。知道你的价格是什么意思，这是你的业务逻辑的问题。

从不同商店的整个应用程序来看，我看到了两个选项。

1. 每个商店应用程序都以自己的货币保存价格。应用程序业务逻辑将是严格的。如果具有不同货币的不同存储需要保持数据库同步，这可能是一个问题。
2. 每个商店应用程序都以相同的货币保存价格。上面的问题消失了，但是应用程序业务逻辑的开销很小，因为它必须在读/写价格到数据库之后/之前进行转换。

顺便说一句，您可能想看看这个关于数据库设计模式的堆栈溢出回答，它提供了推荐的读取。