Ruby on Rails、ActiveRecord、二分搜索
如果我有下表。
create_table :my_table, :id => false do |t|
t.string :key_column
t.string :value_column
end
我如何确保行以最佳方式存储以通过 :key 字段进行二分搜索?
我如何确保使用二分搜索?
If I had the following table.
create_table :my_table, :id => false do |t|
t.string :key_column
t.string :value_column
end
How would I ensure that the rows are optimaly stored for binary search by the field of :key?
And how would I make sure binary search is used?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
对于任何感兴趣的行数,通过键访问单个随机记录的最佳方法(对于“最佳”的大多数定义)是创建索引。
或者在 ActiveRecord 迁移中:
数据库索引通常使用二分搜索,使用 B 树 或类似,它在存储成本和检索和更新时间之间提供了良好的平衡。
对于单表操作,确保使用索引应该相对简单:
例如,应该生成类似这样的内容(检查development.log):
即使是 MySQL 相对不起眼的优化器也应该在最佳运行时没有问题。
行存储不应该成为单个行检索的问题,这是幸运的,因为无论如何您都无法控制它。 对于 MySQL 性能,您可能应该选择 MyISAM 而不是 InnoDB 作为存储引擎,前提是您对“最佳”的定义不包括“最可靠”。
For any interesting number of rows, the optimal way (for most definitions of "optimal") to access a single random record by key is to create an index.
or in an ActiveRecord migration:
Database indices typically use binary search, using B-trees or similar, which offers a good balance between storage costs and time for retrieval and update.
Ensuring the index is used should be relatively straightforward for single-table operations:
for example, should generate something like this (check development.log):
which even MySQL's relatively unimpressive optimiser should have no problem running optimally.
Row storage should not be a concern for individual row retrieval, which is fortunate as there isn't much you can do to control it anyway. For MySQL performance you should probably choose MyISAM over InnoDB as the storage engine, provided your definition of "optimal" doesn't include "most reliable".
准确地存储和检索数据是数据库的工作。 您描述您想要什么,它就会提供您想要的东西。 如果您想具体控制如何执行此操作,那么数据库不是答案。
It's the job of the database to accurately store and retrieve the data. You describe what you want, it delivers it. If you want to control specifically how it goes about doing so then a database is not the answer.