3

问题

我目前有一个产品数据库。这是一个快速模式：

表 bdProduct

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

我现在正处于我想存储价格的地步，我在预测最佳方式时遇到了一些问题。

最终，我很确定我们会走向世界，这取决于我将在哪里销售我的应用程序的商店，这意味着我可能有加拿大元（开始），然后是美元、欧元等。

存储该信息的最佳方式是什么？我已经想过：

| CANPrice |
| USDPrice |
| EURPrice |

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

这是我已经收集到的

  1. 将价格存储在另一张表中（我认为这是最好的方法？）

    有一个 bdProductPrice 我可以保存价格和额外信息

    | idAuto      |
| IDBDProduct |
| RPrice      |
| PriceType   |
| DCreated    |
| ........... |

    我将在其中存储 IDProduct，它的价格和价格类型（是 CAN / USD / EUR）

    我不喜欢这个选项的地方在于，每次阅读产品时我都必须进行另一个查询才能获得它的价格。

  2. 在当前数据库中添加价格

    我不太喜欢这个选项。我觉得它会严重污染我的数据库。我们失去了产品价格的历史，就像谁进行了修改一样。

  3. 你还有什么要建议的吗？

    我们开始吧，我很高兴听到你的消息，你尝试过什么，用过什么……什么对你最有效？

附带问题

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

4

3 回答 3

2

也许我错过了一些东西，但为什么不只是在你的表中添加一个列，也许是 CURRENCY_TYPE，并有另一个表用于参照完整性，这样用户就不能为同一种货币（加拿大元、加拿大元等）添加多个值，而你可以存储您可能想要的有关货币的任何信息。

您仍然需要连接到参考表以获取有关货币的任何信息，但在基表上您将获得价格及其货币类型。

于 2013-08-10T23:14:03.047 回答
0

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

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

因此，我只会在数据库中存储一个价格（如您最初所想的那样）。了解您的价格“意味着”什么是您的业务逻辑问题。

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

  1. 每个商店应用程序都以自己的货币保存价格。应用程序业务逻辑将是直截了当的。如果使用不同货币的不同商店需要保持同步数据库，这可能是一个问题。

  2. 每个商店应用程序都以相同的货币保持价格。上面的问题消失了，但是应用程序业务逻辑会有一点开销，因为它必须在读/写价格到数据库之后/之前进行转换。

顺便说一句，您可能想看看这个关于数据库设计模式的 stackoverflow答案，它提供了推荐阅读。

于 2013-09-21T11:01:53.410 回答
0

不同的方法是可能的，具体取决于您想要实现的目标。

我的建议：

  • 价格：尝试了解您要服务的货币数量，如果它们 <10，则在产品表中添加价格列。在那里您将存储当前价格。在第二个表中，您可以存储价格的历史变化。因此，当您需要显示当前价格时，无需额外加入即可使用。如有特殊需要，历史价值将在那里。如果您的价格超过 10 个，或者您不喜欢多列的解决方案，您可以将价格保存在单独的表格中，例如：

    表 Product_Price

    IDBDProduct
IDCurrency
Price
Start_date
End_date

    使用 End_date，例如 31-DEC-9999 作为当前值（对于获取当前价格也很有用）。

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

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

 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)

最后一件事，就我过去看到的情况而言，通常您在处理产品、价格和描述方面没有性能问题。零售应用程序的大量数据位于销售/交易表中，获取产品描述的附加连接不会损害您的数据库（但这只是 SQL，而不是科学 :)）。

于 2013-10-11T12:30:01.790 回答