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

用例：酒店客房可用性日历

常规方法：

有一个包含以下列的可用性表：（int）hotel_id，（date）date，（boolean）available

< P>这意味着365个行（如果我们考虑一年的可用性）每个酒店索引日期< /P> 我想尝试的东西：

有一个包含以下列的可用性表：（int）hotel_id，（bigint？）availability

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

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

问题：

就性能而言，它值得吗

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

---

<>我会一直等到你有一个很好的索引数据库，并有良好的书面查询，你已经孤立的瓶颈，在你的系统之前，看看这样的事情，老实说，我可能会考虑远离传统的RDBMS（到一些分布式的，也许MangGDB或卡桑德拉）在尝试此方案之前。

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

事实上，您建议的另一种选择要糟糕得多——您可能无法正确地为可用性列编制索引，这意味着按日期进行的查询将极其缓慢

例如，您可能希望运行如下查询：从hotel\u avail中选择hotel\u id，其中Available=TRUE和avail\u date='2011-04-01'；您需要在date列上建立索引，以便快速运行

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

最后，正如@marktozzi提到的，过早优化是个坏主意。尽管RDBMS最近有很多垃圾言论，但它们的性能通常比您预期的要好得多，而且伸缩性出奇地好。他们通常也会为你的问题提供最简单、最可靠的解决方案——20多年的发展是有意义的。

---

在我工作的地方，我们将MS-SQL用于一个每天处理数十亿事务的web应用程序，一些数据库达到数亿行和万亿字节的存储空间。我们也使用NoSQL（Riak、Coach、HBase），但仅限于SQL无法使用的地方。您的系统并非如此。

虽然我理解并完全同意您关于预优化、2000家酒店、每家酒店1+优惠、每家酒店365+可用性记录、5+网站/应用程序的声明，但您可能理解我的担忧。无sql数据库方法是我非常乐意学习的方法，但我仍然不知道它对我有什么帮助。谢谢你的建议！我仍然认为，与位掩码解决方案相比，使用良好的索引更好。2000*365仍然只有大约75万行，这真的没有那么大。您是否有一个现有的系统在数据库上受到限制？通常，在使用位掩码解决方案之前，我会尝试Db/服务器配置、查询优化和索引。即使您可以跟踪位掩码，也会给继承该系统的人留下一个很大的麻烦，最终会有人错误地使用它并获取错误的数据。事实上，如果我按位方式进行查询，我不会按日期而是按掩码进行查询（以前我必须在代码中将日期转换为整数）。使用双向appraoch查询看起来简单/简短，但可读性较差。常规方法更容易理解，但过于冗长（也不会那么容易阅读）…问题是我不会在一个日期前查询（你必须检查停留期间包含的所有日期）。但可能是我的常规方法中的表定义效率不高…？那么您的表定义是什么？请参阅问题“（int）hotel_id，（date）date，（boolean）available”@redben该表定义似乎非常有效-如果您在date列上放置一个索引，那么它将有效地支持范围查询（在date1和date2之间），这应该包括您需要检查停留期间的所有日期。