我正在实现以下模型存储用户相关的数据在我的表-我有2列- uid(主键)和一个元列，其中存储关于JSON格式的用户的其他数据。
uid | meta
--------------------------------------------------
1 | {name:['foo'],
| emailid:['foo@bar.com','bar@foo.com']}
--------------------------------------------------
2 | {name:['sann'],
| emailid:['sann@bar.com','sann@foo.com']}
--------------------------------------------------
这种方法(在性能和设计方面)是否比每个属性一列模型更好?在每个属性一列模型中，表将有许多列，如uid、name、emailid。
我喜欢第一个模型的地方是，你可以添加尽可能多的字段，没有限制。
另外，我想知道，既然我已经实现了第一个模型。我如何对它执行查询，比如，我想获取所有名称为'foo'的用户?
问:在数据库中存储用户相关数据(请记住，字段的数量是不固定的)，使用JSON还是每个字段列?另外，如果实现了第一个模型，如何查询上述数据库?我应该使用这两个模型，通过存储所有的数据，可以在一个单独的行和JSON(是不同的行)的数据查询搜索?
更新
由于没有太多需要执行搜索的列，使用这两种模型是否明智?每列键的数据，我需要搜索和JSON为其他人(在同一个MySQL数据库)?
只是随便说说，但是WordPress有一个关于这类东西的结构(至少WordPress是我第一个观察到它的地方，它可能起源于其他地方)。
它允许无限的键，并且比使用JSON blob搜索更快，但不如一些NoSQL解决方案快。
uid | meta_key | meta_val
----------------------------------
1 name Frank
1 age 12
2 name Jeremiah
3 fav_food pizza
.................
EDIT
用于存储历史记录/多个键
uid | meta_id | meta_key | meta_val
----------------------------------------------------
1 1 name Frank
1 2 name John
1 3 age 12
2 4 name Jeremiah
3 5 fav_food pizza
.................
通过这样的方式查询:
select meta_val from `table` where meta_key = 'name' and uid = 1 order by meta_id desc
似乎您主要在犹豫是否要使用关系模型。
就目前的情况而言，您的示例相当适合关系模型，但是当您需要使该模型演进时，问题当然会出现。
如果您的主实体(用户)只有一个(或几个预先确定的)属性级别，您仍然可以在关系数据库中使用实体属性值(entity Attribute Value, EAV)模型。(这也有利弊。)
如果您希望使用应用程序搜索的结构化值较少，那么MySQL可能不是最佳选择。
如果你在使用PostgreSQL，你可能会两全其美。(这真的取决于这里数据的实际结构……MySQL也不一定是错误的选择，NoSQL选项可能是有趣的，我只是建议替代方案。)
事实上，PostgreSQL可以在(不可变的)函数上建立索引(据我所知，MySQL不能)，在最近的版本中，你可以直接在JSON数据上使用PLV8来在特定的JSON元素上建立索引，这将提高你搜索数据时的查询速度。
编辑:
因为不会有太多的列需要执行
搜索，使用这两个模型明智吗?数据的每列键
我需要搜索和JSON为其他人(在同一个MySQL数据库)?
混合使用两个模型不一定是错误的(假设额外的空间可以忽略不计)，但是如果不能确保两个数据集保持同步，则可能会导致问题:应用程序必须在不更新另一个数据集的情况下更改其中一个。
A good way to achieve this would be to have a trigger perform the automatic update, by running a stored procedure within the database server whenever an update or insert is made. As far as I'm aware, the MySQL stored procedure language probably lack support for any sort of JSON processing. Again PostgreSQL with PLV8 support (and possibly other RDBMS with more flexible stored procedure languages) should be more useful (updating your relational column automatically using a trigger is quite similar to updating an index in the same way).
