价格数据建模

Question

价格数据建模

3

问题

我目前拥有一个产品数据库。这是一个快速的架构：

表bdProduct

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

我现在的问题是如何储存价格，还没有找到最好的方法。

未来，我相信我的应用程序将面向全球销售，这意味着我可能会有加拿大元（起始），然后是美元、欧元等货币。

那么，最佳的储存方式是什么呢？我已经考虑过：

| CANPrice |
| USDPrice |
| EURPrice |

我不知道为什么，但我觉得这不是一个很好的方法。顺便说一下，我过去三年一直在使用该系统（CAN/USD/EURPrice），我们一直在思考如何添加新类型的问题。

以下是我已经收集到的信息

Storing price in another table (I think that would be the best way ?)

Having a bdProductPrice in which I would save the price and extra information
```
| idAuto      |
| IDBDProduct |
| RPrice      |
| PriceType   |
| DCreated    |
| ........... |
```
in which I would store the IDProduct, with it's price and the type of price (is it CAN / USD / EUR)

What I don't like about this option is that I'll have to make another query each time I read the product to get its price.
Adding the price in the current database

I don't like much this option. I feel like it would polute my database much. And we lose the history of the price of the product as much as who made the modification.
Anything else you have to suggest?

Here we go, I'd be happy to hear about you, what have you tried, used... What worked the best for you?

次要问题

我之前问了价格相关的问题，但是对于需要翻译的数据，我也有同样的问题。比如，我会为英语提供一个产品描述，但同时也有法语客户，所以，也许我应该将 bdProductPrice 转换为 bdProductExtension，其中我可以存储我想要给我的产品的信息类型？

- SantaClauss

当你说“将……存储在另一个数据库中”时，你是真的指另一个数据库，还是同一数据库中的另一个表？ - liori

我的意思是另一张表，我说错了 :)。 - SantaClauss

你将要储存"定价列表"。如果你想储存协商价格的历史记录（例如批量订单或优惠客户），那就是一个更大的问题了。大多数销售团队都需要储存这些信息。 - rleir

3个回答

0

根据您想要实现的目标，有多种不同的方法可供选择。

以下是我的建议：

价格：

尝试了解您要服务的货币种类数量是否小于10个，如果是，则在产品表中添加价格列。您可以在该表中存储当前价格。您可以在第二个表中存储价格历史变化。因此，当您需要显示当前价格时，无需进行附加连接即可轻松获取。在特定情况下，价格历史值也将非常有用。

如果您有超过10个价格或者不喜欢使用多列的解决方案，则可以将价格保留在单独的表中，如：

Product_Prices表
```
IDBDProduct
IDCurrency
Price
Start_date
End_date
```
对于当前值，可以使用End_date设为31-DEC-9999（也很有用）。
描述：通常它们是文本字段甚至包含html标签。就像价格一样，您可以采取相同的方法，将其放在产品表中或单独保留，并且只在需要时使用它们。您甚至可以拥有简短和长的描述，前者在产品表中，后者在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而不是科学 :)）。

- mucio

非常感谢您提供的信息，这实际上是我在这里与朋友交流后采取的方式。 - SantaClauss

0

在我看来，数据库是存储信息的地方，将语义信息移动到数据库中通常是不必要的开销（超出数据库模式自身提供的范围）。

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

因此，我只会将价格存储在数据库中（就像您最初想的那样）。这是您的业务逻辑了解您的价格“意义”的问题。

从整个应用程序的角度来看，对于不同的商店，我看到两种选择。

每个商店应用程序以其自己的货币保留价格。应用程序业务逻辑会很简单。如果需要保持同步的不同货币的不同商店，则可能会有问题。
每个商店应用程序以相同的货币保留价格。以上述问题消失，但是应用程序业务逻辑会略有开销，因为它必须在读取/写入价格到数据库之前/之后进行转换。

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

- ASBH

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rock · Accepted Answer

也许我漏掉了什么，但为什么不在您的表中添加一列，比如CURRENCY_TYPE，然后使用另一个表来保持引用完整性，以便用户无法将多个值放入相同的货币（例如CAN、加元等），并且您可以存储任何您想要的有关货币的信息。

对于任何有关货币的信息，您仍需要连接参考表，但在基本表中，您将拥有价格及其货币类型。