键/值（一般）和东京内阁（python tc 特定）问题
我已经进入 RDBMS 世界很多年了，但希望探索整个 nosql 运动。所以这是我的第一个问题：
存在重复密钥的可能性是不好的做法吗？例如，以姓氏（最有可能是搜索项？）为键的地址簿可以有多个实体。那么使用姓氏是不好的做法吗？密钥应该是实体最“可搜索”的定义吗？在这个全新的世界（对我来说）有“最佳实践”的资源吗？
我对东京内阁（特别是 tc 接口）很感兴趣，但不知道如何迭代具有相同密钥的不同实体（例如见上文）。我只能得到第一个实体。不管怎样，预先感谢您的帮助
i have been in the RDBMS world for many years now but wish to explore the whole nosql movement. so here's my first question:
is it bad practice to have the possibility of duplicate keys? for example, an address book keyed off of last name (most probably search item?) could have multiple entities. is it bad practice to use the last name then? is the key supposed to be the most "searchable" definition of the entity? are there any resources for "best practices" in this whole new world (for me)?
i'm intrigued by tokyo cabinet (and specifically the tc interface) but don't know how to iterate through different entities that have the same key (e.g. see above). i can only get the first entity. anyway, thanks in advance for the help
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于 no-sql 实现。例如，Cassandra 允许范围查询，因此您可以对数据进行建模以对姓氏或全名（从姓氏开始，然后是名字）进行查询。
除此之外，许多更简单的键值存储确实需要您为多值条目存储列表结构（或类似结构）。这是否可行取决于预期的“重复项”数量——我认为，对于姓氏，数量可能会相当高，所以对于很多情况来说，这听起来并不是一个理想的模型。
This depend on no-sql implementation. Cassandra, for example, allows range queries, so you could model data to do queries on last name, or with full name (starting with last name, then first name).
Beyond this, many simpler key-value stores would indeed require you to store a list structure (or such) for multi-valued entries. Whether this is feasible or not depends on expected number of "duplicates" -- with last name, number could be rather high I presume, so it does not sound like an ideal model for many cases.
在键值存储中，不能有重复的键，键后面有一个值。要拥有重复的键，您可以使用 Tokyo Cabinet 中的 B+ Tree 数据库，该数据库具有已排序的值并允许重复（您可以通过使用该键并迭代的第一个项目来访问它们）。
并非所有问题都可以通过键值存储轻松解决，因为您需要密钥来检索项目。也许像 MongoDB 这样的东西更合适，因为允许更复杂的查询。
In a key-value store you cannot have duplicate keys, there's a single value behind a key. To have duplicate keys you can use the B+ Tree database in Tokyo Cabinet that has values ordered and allows duplicate (you can acces them by going to the first item with that key and iterating).
Not all problems are easily solved by a key-value store as you need the key to retrieve the item. Maybe something like MongoDB is more appropriate as allows more complex queries.