存储/查询二进制序列rdbms值得吗？

Question

用例：是酒店客房可用性的日历。

常规方法：

有一个具有列的可用性表：(int) hotel_id、(日期)日期、(布尔值)可用

这意味着365行(如果我们考虑一年的可用性)每个酒店的索引日期。

我想尝试的东西：

有一个列的可用性表：(int) hotel_id，(bigint?)可用性

每家酒店1行，使用按位运算符查询查找/更新可用性：

SELECT * FROM table WHERE (availability & mask) = mask

问题：

就性能而言，值得吗？

Answer 1

用Knuth的话来说，“过早的优化是编程中所有邪恶(或至少大部分)的根源。”任何模糊的现代数据库都应该能够处理表中的数百万行，因此365行/酒店/年将扩展到相当多的酒店--在成为问题之前的几年。您所建议的优化会增加相当大的维护成本，因为您的查询更难手工调试。它还使得索引表变得更加困难，这是一个重大的损失，因为大多数RDBMS系统都有充分的设备来利用索引，但是没有很好的设备来优化查询中的位数。

我会等到您真正拥有一个索引良好的数据库，并将这些查询作为系统中的瓶颈进行隔离，然后再进行类似的研究。老实说，在尝试此方案之前，我可能会考虑从传统的关系数据库管理系统(改为分布式数据库管理系统，可能是MongoDB或Cassandra)。

Answer 2

除非您的行数超过10^7，否则数据库引擎应该做得很好，因此，根据您的数字，您建议的常规方法没有什么问题。即使到了那里，一个更强大的服务器(扩展)和一个好的DBA也可以帮助您进一步扩展。

事实上，您建议的替代方案要糟糕得多--您可能无法正确地索引可用性列，这意味着按日期查询将非常慢！

例如，您可能希望运行这样的查询:从hotel_id hotel_avail中选择avaliable = TRUE 和avail_date = '2011-04-01'；您需要在date列上索引才能快速运行。

除此之外，滚动自己的可用性和掩码方案增加了系统的复杂性。理解和维护执行“可用性魔法”的代码将更加困难。相信我，我曾经去过那里--一开始它看起来很漂亮，但过了一段时间，你就记不起你的那些把戏是如何运作的，它变成了一场噩梦。

最后，就像@mark提到的那样，过早的优化是个坏主意。尽管RDBMS最近听到了很多废话，但它们的表现通常比您预期的要好得多，而且扩展得非常好。它们通常也能为您的问题提供最简单和最可靠的解决方案-- 20+多年的开发相当于某种东西。在我工作的地方，我们使用MS作为一个web应用程序，它每天处理数十亿个事务，一些数据库达到数亿行和存储的地形字节。我们还使用NoSQL (Riak、Couch、HBase) --但只在那些不能使用的地方使用。你的系统不是这样的。