我有你期望的标准表，例如“房间”，“预订”等。一切都在关系数据库中。
“预订”表存储了room_id，入住日期和退房日期等项目。
现在，简单地说，当进行预订时，系统会检查“RoomPrice”表并获取每晚保留的费用（取决于日期，入住率等） - 费用可能会有所不同每晚取决于当前的价格 显然，当预订时，每晚的价格是固定的。因此，即使房价在事后更新，该预订仍然按照商定的价格保持，因为它是在价格变动之前进行的。
我的问题是：在预订时，我应该如何存储这些个人约定的价格？
我正在考虑使用另一张桌子“PriceForNight”，它会存储预订的每个晚上的预订ID，价格和日期。
我看到的唯一可能的问题是可扩展性。如果平均预订长度为5晚，则意味着“PriceForNight”表的增长速度将比“预订”表快5倍。
'PriceForNight'数据会更好地存储在NoSQL数据库或类似的东西中吗？
正在考虑的另一个选项是将每个夜晚的价格存储为“预订”表格行中单个列中的逗号分隔字符串，例如：“150.00,175.00,175.00,200.00,150.00”为5晚上预订。
我可能过度思考这个问题，因为真正的问题可能只有在增长1000倍的情况下才会存在，但我喜欢做正确的事情，所以我想我会联系社区。
非常感谢任何输入。
答案 0 :(得分：3)
纯粹的关系方法是拥有一个ReservationNight表，该表存储有关预订的每个晚上的详细信息，包括价格。是的，表格会快速增长，但无论您如何存储价格，数据都会快速增长。
答案 1 :(得分：1)
通常，逗号分隔的列表不属于SQL数据库。我会说你最好的选择是联络表。
StackOverflower Bill Karwin在这里回答得最好：Is storing a comma separated list in a database column really that bad?
除了违反First Normal Form因为 重复存储在单个列中的值组，以逗号分隔 列表还有许多其他更实际的问题：
- 无法确保每个值都是正确的数据类型：无法阻止 1,2,3，banana，5
- 无法使用外键约束将值链接到查找表;无法强制执行参照完整性。
- 无法强制执行唯一性：无法阻止 1,2,3,3,3,5
- 如果不提取整个列表，则无法从列表中删除值。
- 很难在列表中搜索具有给定值的所有实体;你必须使用低效的表扫描。
- 难以计算列表中的元素，或执行其他聚合查询。
- 很难将值加入他们引用的查找表中。
- 难以按排序顺序获取列表。
要解决这些问题，你必须编写大量的应用程序代码， 重新发明RDBMS 已经提供的功能 有效地
以逗号分隔的列表是错误的，我把它作为第一个 我书中的一章：SQL Antipatterns: Avoiding the Pitfalls of Database Programming。
有时你需要使用非规范化，但是@OMG 小马提到，这些都是例外情况。任何非关系型的 “优化”有利于一种查询而牺牲其他用途 的数据，所以一定要知道你的哪些查询需要 特别对待他们应该进行非规范化。
答案 2 :(得分：0)
您可以使用日期范围而不是固定日期。
所以，如果我预订：
Night 27 01 2012: 20 $
Night 28 01 2012: 20 $
Night 29 01 2012: 30 $
在db：
reservationId from to price
5457848 20120127 20120128 20
5457848 20120129 20120129 30
如果每天都有一个不同的价格是非常普遍的，这不会减少行数。但它很少见，然后它会减少大多数到1行。
答案 3 :(得分：0)
存储每晚成本的表格，每晚一行似乎是明智的。
每间客房每年租用不超过365晚。 （在现实世界中，几乎是真的。汽车旅馆业务实际上比看起来更复杂。）
如果你有200个房间，你会看到大约200 * 365行，或每年73,000行。 （我的算法是否合适？）按照这个速度，如果技术根本没有改进，你就不必考虑担心SQL dbms至少100年的性能。
您可能还会发现this answer有用。它遵循同样的思路。