将冗余信息添加到数据库以简化查询模型

Question

让我们想象一下，我有类似以下人为的例子

ParkingSpace         Car                   ParkingSpaceCar
-------------        -------------         ---------------
Id                   Id                    ParkingSpaceId
                     Date                  CarId

所以我有所有已经分配到任何特定停车位的汽车的历史，这很棒。

但是为了找到当前分配的汽车，我必须在Date中的最新Car上进行查询匹配，这会增加LOC和性能方面的开销。

所以我的问题是，在IsCurrent上添加ParkingSpaceCar字段以简化数据提取是可以接受的，即使它实际上是一个冗余字段（因为它可能来自已存在的数据）

注意：我对答案一般感兴趣，我知道上面的具体例子有点傻。

Answer 1

如果我要设计数据库，我会这样做

ParkingSpace         Car                   ParkingSpaceCar
-------------        -------------         ---------------
Id                   Id                    ParkingSpaceId
                                           CarId
                                           ParkDate

因此每次我查询时我都会使用停放日期，其中包含每个细节（CarID和ParkSpaceID）

我可以通过ParkDate对所有内容进行排序。

Answer 2

拥有高度规范化的模型非常棒，因为通常可以为设计人员提供有关域数据模型的大量知识。

但是，一旦开始编写查询，裂缝就会开始显示。确实，规范化的数据库将能够回答每个查询，并使用较少的空间来存储数据，但是以加入之后的加入价格（例如，发票的税率来自{{1} }表通过Taxes表通过TaxesByCounty表通过Counties表），以及聚合函数之后的聚合函数（例如发票的总价值）不断根据订单项计算，而不是存储在Cities表中）。

因此，一旦真实数据涌入数据库，并且一些真实的查询被写入，那就是denormalization时间。非规范化实际上会在需要的地方复制数据，有时可能会产生一些维护困难，但值得付出努力。应该通过一些性能指标来指出应该复制哪些数据，但通常会有一些明显的候选者。

Answer 3

这个模型对我来说没什么意义。无论如何，似乎日期属于ParkingSpaceCar表。因此答案是否定的。确保您的数据库处于Normal Form状态，问题可能会消失。避免在设计中引入偏差以支持对数据的一种特定类型的操作，因为这通常只会使其他操作更复杂。

Answer 4

是的，有时这样做是合适的。

这个的一般术语是denormalizaton：为了获得一些优势（通常是查询性能），您主动破解一些rules of normalization。

由于规范化具有很多优点，因此如果改进的性能超过缺点（例如数据不一致的可能性），则应仔细考虑。

Answer 5

我广泛采用星型模式/数据仓库方法。

• DimDate（每个日期一行，主键kDate）
• DimCar（每辆车一排，主钥匙kCar）
• DimParkingSpace（每个停车位一排，主键kParkingSpace）

然后创建一个Fact表

• FactParkingAllocation（每辆车一行，日期和停车位，外键kDate，kCar，kParkingSpace）

我不打算在FactParkingAllocation表上显示当前的标志，因为这需要经常更新，相反，我会根据'今日'日期在桌子上查看哪个子集（我'将SQL逻辑留给您，因为这取决于您的DBMS）。