数据库设计的最佳方式

时间:2014-01-03 23:43:34

标签: database-design

我正在尝试为我的数据库找到最佳解决方案。

我有什么

优惠

DateOffer                       the date the offer is made
RateId                          foreign key to table with price/tax rates
Hours                           ammount of hours worked
Buissnes (boolean)              is it for a buissnes 
                                (yes tax = WorkTaxBuissnes no = WorkTax)
ExtraHours (boolean)            if extra hours calculate with ExtraHourRate

价格

RateId
WorkTax 
WorkTaxBuissnes
NormalHourRate
ExtraHourRate

你可以看到我需要在另一张表中查找税,是否更明智地获得索引税并将值添加到表中以便我可以从表中提供所有内容。

我可以将Buissnes(报价)更改为税务,并将工作时间(提供)改为WorkTax。

优点是我不需要使用任何加入或者如果检查(排除是否?是不是?)。

缺点是我无法看到它是否是额外的时间,或者我是否计算了buissnes税(因为它们会改变)或者我可以将它们作为额外的字段保留。

有人可以给我建议。

3 个答案:

答案 0 :(得分:1)

如果费率是可更新的实体,则阻止在优惠表中保留这些实体的副本。

考虑我们在费率表中有费率-1(记录),假设我们将有10个与此费率-1相关的要约(要约1 ...要约10)。
在插入要约后我们决定更新率-1值 场景1:将值添加到表格中(取消规范化)
当插入offer-1,offer-2,... offer-10时,我们将从报价内的费率中保留冗余数据 插入后,当rate-1的更新发生时,我们需要更新offer-1 .. offer-10
至少需要11次更新(1次为1次,10次为优惠) 优点:

  • 根据费率计算报价成本将快速完成,不需要 额外加入。

缺点:

  • 我们在10条记录中冗余了相同的数据。
  • 我们强制进行了10次额外更新。
  • 如果任何更新失败,我们将有不一致的数据

场景2:将费率相关值保持在费率表(标准化)
缺点:

  • 报价成本的计算基于费率表数据,我们需要额外的联接来获取费率。获得较少的性能。这将导致性能损失。

优势:

  • 我们将费率数据保存在一个地方,我们获得了一致性。
  • 当更新费率时,我们保持了数据的完整性。

标准数据库设计指南是设计人员应首先创建fully normalized dsign,然后出于性能原因执行选择性denormalization

规范化是组织关系数据库的字段和表以最小化冗余和依赖性的过程。
非规范化是尝试通过添加冗余数据或对数据进行分组来优化数据库读取性能的过程。

提示:构建第一个数据库的程序员通常主要关注性能。毫无疑问,表现很重要。糟糕的设计很容易导致数据库操作需要十到一百倍的时间。

答案 1 :(得分:0)

也许我错了,但在这个简单的情况下,即使价格非常有限,我也会看到你的第二个选项效率更高。

存储要求(费率数量非常有限):

  1. 日期+ 2 x 4字节+ 2 x 1字节(如果您的数据库支持tinyints)=日期+10字节。 (我不添加费率的存储,因为我认为它们是有限的)
  2. 日期+ 5 x 4字节(如果您可以保存费率ID)=日期+20字节。
  3. 因此,由此产生的空间将减少一倍,但如果涉及额外的时间,查询将会快得多。另外,您可以直接在一个表格中根据费率值执行查询。

    如果空间不是问题,那么毫无疑问,请采取第二种方式。 如果有很多费率案例相同的话。

答案 2 :(得分:0)

我的最终解决方案。

我保存了数据库,就像我的例子一样,所以我不会有任何双重数据,(相同税率的2倍)

但是我添加了一个View作为一个表格,但实际上是一个在其他表格上运行的查询,并返回可以使用的值,就像像myview一样的表格