1

我正在尝试为高尔夫球场定价概览网站找出最佳设计。

保存最终价格的表格如下所示：

clubid,courseid,seasonid,holesid,timeid,personid,rate

字段为：

  • clubid：高尔夫球俱乐部的ID courseid：一个俱乐部可以有多个球场
  • seasonid：俱乐部/球场有多个赛季（高、平、低、...）
  • holeid：玩家可以打的洞（18,9,allday,...）
  • timeid：根据一天中的时间可以有多种费率（早期，黄金，黄昏，...）
  • personid：根据人的类型，可以有折扣（学生、高级）或加价

所有这些都将在列出各种选项的相应表格中进一步定义。

现在至于我的问题：

  1. 这个概念是否存在重大设计错误，我想看看？
  2. 这种设计的查询速度有什么问题吗？我觉得这种多维设计最令人不安的是关于数据输入的问题。
  3. 在这种结构中输入数据的最佳方式到底是什么？

我有一个勉强可行的选择，但目前还不想影响其他人的想法。

4

3 回答 3

2

在这里检查。这会帮助你。这有多种数据模型。它还包含用于高尔夫管理。

http://www.databaseanswers.org/data_models/golf_club_management/index.htm

于 2013-01-27T10:43:24.283 回答
1

您提出的星型模式设计有两个可能的问题。

问题 1：灵活性

通过将价格确定标准设置为查找表的一组固定外键，您创建了一种情况，即您要跟踪价格的每门课程都必须以某种方式适应该方案。一旦您与创意营销经理一起参加课程，您就会发现自己不得不修改您的架构以适应该课程。

问题 2：数据输入工作

正如您已经注意到的那样，拥有一组固定价格决定因素意味着所有这些决定因素的交叉产品是需要维护的大量数据。令人沮丧的是，对于许多课程来说，一些决定因素并不重要。

另一个可能令人沮丧的事情可能是每门课程对每个决定因素都有自己的解释。例如，旺季对每门课程意味着什么？如果你不关心这些细节，那么你就可以了，但如果你真的必须用具体的术语来解释自己（即我们所说的课程X的“高峰”是什么日期？），那么你也会有很多价格维度表中的数据。

解决问题：

如果您愿意使用更复杂的数据模型，则可以显着减少数据管理量。您可以表驱动决定因素，而不是具有一组固定价格点决定因素的星型模式。架构将是这样的：

COURSE              -- The list of courses you are tracking
  courseid (PK)
, name

COURSE_PRICE_POINT  -- An individual price point for a course
  cppid (PK)
, courseid          -- FK to COURSE
, price             -- The amount, if your system is multi-currency, include a code 
                    -- for the currency, e.g. GBP, EUR, USD, etc.

COURSE_PRICE_FACTOR -- The list of factors that make a specific price point applicable
  cppid (PK)        -- PK, also FK to COURSE_PRICE_POINT
, pfid (PK)         -- PK, also part of FK to FACTOR_VALUE
, fvid              --     the other part of the FK to FACTOR_VALUE

FACTOR_VALUE        -- A lookup table of price factors, e.g. "Peak Season", "18 Holes"
  pfid (PK)         -- PK, also FK to PRICE_FACTOR
, fvid (PK)
, value             -- Description of the price factor value

PRICE_FACTOR        -- A list of the dimensions that impact price, 
                    -- e.g. Season, Holes, Person, Time
  pfid (PK)
, description       -- A caption/name for the price factor.

该模型的工作方式是，对于课程可能收取的每个特定价格，您在COURSE_PRICE_POINT. 如果您的星型模式表可能具有尽可能少的行数，则此表中将有一条记录，即您在星型模式定价表中可能拥有的每条记录。

星型模式定价表中的价格决定因素列变为PRICE_FACTOR. 可能出现在行列式查找表中的值成为FACTOR_VALUE. 这部分的工作量是相同的，除了如果您发现需要添加新的价格因素，您需要做的就是输入一些新数据而不是更改您的表定义，这是您将面临的问题星型模式方法。

要将价格点实际固定到其决定因素，您需要填充COURSE_PRICE_FACTOR以将价格点连接到定义价格点所需的最小因素值集。请注意，FACTOR_VALUE由其 FK 标识为PRICE_FACTOR。这意味着 的 PK作为 FK 的一部分存在PRICE_FACTOR于. 这很重要，因为它允许您在价格点 ID 和价格因素 ID 的组合上定义唯一索引（我已将该组合作为表的 PK）。这意味着模式将施加限制，即您不能对相同的价格因素有矛盾的值，这是一个很好的小数据一致性约束。COURSE_PRICE_FACTORFACTOR_VALUE

所有这些似乎都需要做很多工作，那么为什么它比星型模式更好呢？看一个例子，假设您的星型模式中有季节、洞、时间和人物的四个变体。这可能是一个低估，但让我们继续吧。这意味着您需要每门课程 4 x 4 x 4 x 4 = 256 条记录来跟踪所有定价变化。如果一门课程有一个非常简单的价格卡，比如：“淡季是你每天 100 美元可以玩的全部”。这将是我建议的模型中的一个价格点，但星型模式仍需要 1 x 4 x 4 x 4 = 64 条记录。

更糟糕的是：对于星型模式，根据您打算如何使用它，您可能有一条规则，即每个查找表值需要在每门课程的定价表中表示。这意味着添加一个新记录，比如赛季将需要在每门课程中创建一堆新记录，即使其他课程不识别您的新维度值。

我建议的模型的主要优点是（i）您可以在特定条件下对特定课程的定价非常具体和准确，以及（ii）您的数据维护最小化。

这个模型的缺点是什么？此模型对于为一门课程与另一门课程设置价格比较图表不会很有帮助。如果您要比较的两个课程的定价结构非常不同，那么很难找到一种方法在并排的价格比较表中显示价格表。

于 2013-01-27T13:37:08.310 回答
0

概念看起来不错，查询的速度将取决于每个变量的数量，但是使用良好的索引应该很容易优化，courseid并且seasonid看起来像快速候选者。这也很好地提供了一个树形结构，您可以将其加载到内存中，这将具有惊人的快速查找时间。

您正在做的事情很常见 - 它被称为Star schema，我知道许多金融机构都以这种方式处理他们的定价。

于 2013-01-27T10:48:26.573 回答