如何在数据库级别设计定价模块答案

【问题标题】：how to design pricing module at database level如何在数据库级别设计定价模块
【发布时间】：2012-02-17 11:22:39
【问题描述】：

我想在数据库中建模如下场景：

我有一个包，由独立的Activities 和Hotel 组成：

包P：

Activities 和Hotel 是独立的实体，在定义实体时定义了自己的价格。

当一个实体被添加到包中时，它的价格可以改变（仅限specific to the package）。因此，每个套餐对于活动/酒店都有一个独特的价格。

例如 (Defining activities and hotel):

A1 - 10$
A2 - 20$

H1 - 100$

(Adding activities and hotel to package):

Package p;
p.addActivity("A1", 15);
p.addActivity("A2", 25);
p.addHotel("H1", 50);

yields => 

p
 - A1 - 15
 - A2 - 25
 - H1 - 50

数据库端：

定义：

添加到包后

Package-id、Hotel-id、Activity-id

Package-Activity price table:

Package-id、Activity-id、Price//package-id 和 activity-id 作为唯一键
Package-Hotel price table:

Package-id、Hotel-id、Price//package-id 和hotel-id 作为唯一键

我需要一些关于我提出的设计的反馈。我是否过于复杂了？有没有更简单/更好的方法来做到这一点？另外，在我写这篇文章的时候，我想一个包可以有很多酒店和活动，所以需要在这里考虑。我是否过于分散了这一点，因为对于实体的每次价格查询，我都将执行连接？

编辑

找到了有关使用 Joins 的性能的相关链接：When and why are database joins expensive?

【问题讨论】：

【解决方案1】：

这里确实需要五张桌子。

您有三个实体：活动、酒店和套餐（假设每个套餐都有一些与酒店或活动无关的数据）。您有两个关系，都是多对多的，即 package-hotel 和 package-activity。每个关系行都标有特定价格。

五张桌子是要走的路。不，必须进行连接不是问题：这比拥有非正常数据要好。您可以在以后如有必要进行非规范化以提高性能。

【讨论】：

我有点困惑。因此，我们为所有活动提供了 1 张桌子。包可以包含多个活动，所以我需要一对多的关系。我假设 Package-activities 表是解决这个问题的方法。我想保留一个单独的定价表，所以我有一个 Package-activities-price ，正如我在我的问题中列出的那样。正确吗？
@brainydexter：不。首先，一个包可以包含多个活动，但一个给定的活动可以在多个包中。那是多对多的关系。现在，当您有一个多对多连接表时，您不必将自己限制在两个字段中，因此价格可以与package_id 和activity_id 一起在该表中。你为什么要单独列出价格表？它必须也具有 ID，以便您知道价格指的是什么。