非关系数据库、键值或平面表
我的应用程序需要可配置的列，并且这些列的标题是在开始时配置的，如果是关系数据库，我会在表中创建通用列，如 CodeA、CodeB 等以满足此需要，因为它有助于对这些列进行查询（Code A = 11）还有助于显示值（如果该列存储代码和值），但现在我正在使用非关系数据库数据存储（而且我是新手），我应该遵循相同的旧方法还是应该使用集合（键值对）结构类型。
这些列上会有很多过滤器。请建议
My application needs configurable columns , and titles of these columns get configured in the begining, If relation database I would have created generic columns in table like CodeA, CodeB etc for this need because it helps queering on these columns (Code A = 11 ) it also helps in displaying the values (if that columns stores code and value) but now I am using Non Relational database Datastore (and I am new to it), should I follow the same old approach or I should use collection (Key Value pair) type of structure .
There will be lot of filters on these columns. Please suggest
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您刚才描述的是键值数据库的经典场景之一。这里的限制是您不会拥有许多您习惯的基于集合的工具。
大多数 KV 数据库非常擅长加载一条“记录”或一小组“记录”。然而，它们往往不擅长加载任何可能需要连接的东西。鉴于您正在使用 AppEngine，您可能会意识到这一限制。但值得一提的是。
需要注意的是，并非所有 KV 数据库都允许您“按任何列进行选择”。许多 KV 存储实际上只允许通过主键进行选择。如果您查看一下 MongoDB，您会发现您可以查询任何听起来像是必要功能的列。
What you've just described is one of the classic scenarios for a Key-Value database. The limitation here is that you will not have many of the set-based tools you're used to.
Most of the K-V databases are really good at loading one "record" or small set thereof. However, they don't tend to be any good at loading anything that may require a join. Given that you're using AppEngine, you probably appreciate this limitation. But it's worth stating.
As an important note, not all K-V database will allow you to "select by any column". Many K-V stores actually only allow for selection by a primary key. If you take a look at MongoDB, you'll find that you can query any column which sounds like a necessary feature.
我建议使用键/值对，其中键将充当您的列名称，值将是其数据。
I would suggest using key/value pairs where keys will act as your column names and value will be their data.