创建定价矩阵 - sql 还是常量数组？

Question

我计划为 Rails 中的一个项目创建一个定价矩阵。它应该是一个目的地和出发地点的表格，价格取决于您来的地方和计划去的地方。

我还没有决定如何更好地做到这一点：要么在数据库中为此矩阵制作一个表，要么制作一个大型常量数组。问题是，客户端应该能够编辑这个矩阵，因此它最有可能走数据库路线。

无论如何，什么是一个好的模式呢？目的地id，出发地id，然后价格？目的地和出发 ID 将是包含所有可能位置的表的外键。有更好的方法吗？

Answer 1

使其成为数据库表。

价格唯一不变的就是它们会变化。

补充：

定价（也称为产品保理）是我有很多经验的事情。

您的客户可能还会要求/或欣赏额外的定价工具来帮助他们把事情做好。例如，您的 sw:

• 可以拥有以专为定价人员设计的方式显示价格的报告。
• 报告最高、最低价格（以帮助发现数据输入错误）
• 查看定量信息的视觉设计，了解如何直观地显示目的地对的价格的想法
• 确保目的地/出发地对仅添加一次。 （另一个方向没有重复。）
• 等

您可能还需要担心定价的有效日期。即如何以协调的方式推出一套新的价格。

Answer 2

我将使用两个表：Location 和 TravelPrice。

Location
----------
LocationID --PK
Name

TravelPrice
-------------
TravelPriceID --PK
DepartureLocationID --FK to Location
DestinationLocationID --FK to Location
Price
StartDate --date the price is effective from
EndDate --date the price is effective to (or NULL)

这使您可以保留价格历史记录，这对于报告、计费等非常重要。理想情况下，您可以在 TravelPrice 表上触发，确保给定 DepartureLocationID 的日期没有间隙或重叠/DestinationLocationID 组合，并且该对中只有一个 EndDate 为 NULL 的记录。

Answer 3

我会将其添加到 3 列表中，因为它不一定是矩阵 - 您可能不会从所有地方旅行到所有其他地方。您希望能够编辑它。完成硬编码版本后，系统会要求您对其进行编辑。

LeavingFrom, TravellingTo, Price

此外，随着目的地列表的增长，查询性能和代码维护将成为一个因素。