存储属于列表的大量对象
我正在使用 Rails 并有以下场景：用户有很多列表，每个列表包含多个单词，每个单词都有自己的定义。列表显示视图显示按 30 的倍数分页的所有单词。我担心 b/ca 列表可能会增长到超过 4,000 个单词，如果需要对列表进行排序，这似乎对数据库进行分页会非常昂贵按字母顺序排列。我想知道最快的方法是什么。也许在这个词上添加一个索引？
我考虑过在列表中保存一个字符串，其中包含列表中以空格分隔的所有单词。然后我可以对此字符串执行 split(" ") 并在此数组上使用分页，但随后我需要使用正则表达式从该列表中添加和删除单词以及保存单词对象。
我还考虑过某种键值存储，例如东京橱柜。看起来 B 树索引可以工作。
I am using rails and have the following scenario: Users have_many lists and each list contains a number of words with each word having its own definition. The list show view shows all the words paginated by multiples of 30. I am concerned b/c a list can grow to have over 4,000 words and this seems like it would be way to expensive for the database to paginate if the list needs to be ordered alphabetically. I'm wondering what the fastest way to do this is. Maybe adding an index on the word?
I have considered saving a string in the list that contains all the words in the list separated by a space. I could then do a split(" ") on this string and use pagination on this array, but then I need to use regular expressions to add and delete words from this list along with a word object save.
I have also considered some sort of key-value store like tokyo cabinet. It looks like a B-Tree index could work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
索引它！这是迄今为止最好的选择，就像 Mark Thomas 所说，它会为您提供任何 30 个连续单词，就像它为您提供前 30 个单词一样快。只需输入
:order并a:limit就可以了 - 或者更好的是，让像 will_paginate 为您完成这一切。单词字符串是一种非常混乱的方法 - 每次添加或删除单词时都必须重建字符串，并且工作查找必须使用缓慢的比较函数，例如
LIKE或REGEX< /代码>。东京（现在的京都）内阁可能不够通用，无法满足您的需求 - 它声称是一把钥匙 ->值存储，并且您可能需要多个键 ->值，我不确定它是否支持。此外，既然已经有了一个数据库，为什么还要添加另一个数据库呢？
tl;dr INDEX!
希望这有帮助！
Index it! This is by far the best option, and like Mark Thomas said, it'll give you any 30 consecutive words just as quickly as it'll give you the first 30. Just throw in an
:orderand a:limitand you're good to go - or, better yet, let a plug-in like will_paginate do it all for you.The word string is a pretty messy approach - you'd have to rebuild the string every time you added or removed words, and work lookups would have to use slow comparison functions like
LIKEorREGEX.Tokyo (now Kyoto) Cabinet might not be versatile enough for what you need - it claims to be a key -> value store, and you might need multiple keys -> value, which I'm not sure it supports. Besides, why add another DB when you've already got one?
tl;dr INDEX!
Hope this helps!