我正在实现以下模型存储用户相关的数据在我的表-我有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
和大多数事情一样，“视情况而定”。将数据存储在列或JSON中本身没有对错/好坏之分。这取决于你以后要用它做什么。您预计使用什么方式访问这些数据?您是否需要交叉引用其他数据?
其他人已经很好地回答了技术权衡是什么。
没有多少人讨论过你的应用程序和功能会随着时间的推移而发展，以及这个数据存储决策如何影响你的团队。
因为使用JSON的诱惑之一是避免迁移模式，所以如果团队没有纪律，很容易在JSON字段中插入另一个键/值对。它不需要迁移，没有人记得它是干什么用的。它没有验证。
我的团队在postgres中使用JSON和传统列一起使用，起初这是自切片面包以来最好的东西。JSON是有吸引力和强大的，直到有一天我们意识到灵活性是有代价的，它突然成为一个真正的痛点。有时，这个点很快就会上升，然后就很难改变了，因为我们已经在这个设计决策的基础上构建了太多其他东西。
随着时间的推移，添加新功能，使用JSON格式的数据会导致看起来比使用传统列所添加的查询更复杂。然后我们开始把某些键值捞出来放到列中，这样我们就可以在值之间进行连接和比较。坏主意。现在我们有了复制。一个新的开发人员会感到困惑吗?我应该存回哪个值呢?JSON还是列?
JSON字段变成了存放这个和那个小碎片的垃圾抽屉。没有数据库级别的数据验证，文档之间没有一致性或完整性。这将所有的责任推到应用程序中，而不是从传统的列中获得严格的类型和约束检查。
回顾过去，JSON让我们能够快速迭代并创造出一些内容。太棒了。然而，当我们达到一定的团队规模后，它的灵活性也让我们陷入了技术债务的长绳中，从而减缓了随后的功能开发进程。请谨慎使用。
仔细思考你的数据的性质是什么。这是你的应用程序的基础。随着时间的推移，数据将如何使用。它可能会发生怎样的变化?
