最近我发现自己为大多数主表创建了元表。
例如 ，我的用户表包含密码、电子邮件和 ID，以及一些时间戳。但是诸如用户来自哪里、他们的个人资料图片或他们最喜欢的颜色之类的信息我存储在 user_meta 表中。一些详细信息，例如联系人，我在元表中存储为 JSON 值(数组)，键是 contacts，值是带有联系人详细信息的 JSON 数组。
我的理由是，它使我可以更轻松地更改前端和添加功能/细节，而无需处理服务器端的事情。
话虽如此，我担心我必须经常获取元表，这会影响性能。在上面概述的情况下，每次显示用户列表时我都必须获取元表，以便我可以获取他们的个人资料图片。
什么时候创建一个单独的键值元表而不是仅仅使用特定的列更好？
最佳答案
您所做的不一定是不正确的，但是，“元”表并不是描述您要实现的目标的正确方法。
没有什么说你不能有一个与用户1:1关系的user_profile，以及具有不同类型关系的附加表——例如一对多。
在事情的 JSON 方面:您的用户联系人数据通常不会在结构上发生变化，因此您可以假设每个用户有一个或多个联系人，只需创建一个具有 1:n 的 user_contacts 表。我个人也不喜欢用“meta”作为后缀来表示一些自引用，因为它太模糊而无法描述可能是什么内容(特别是如果您还有一个或多个具有 JSON 数据类型的列)。如果结构经常变化以保证它有用，我会选择 JSON 数据类型。
如果您的用户数据的结构经常变化，您可能需要考虑使用 NoSQL 数据库，或者您可能有一个单一的“元”表，如您所描述的，具有几个 JSON 数据类型，其中该数据的结构是可变的，你不需要经常解包数据以至于它很痛苦......
对此进行一点扩展。没有硬性规定，但通常情况下，如果您的表要存储大量行，您可以保持紧凑并仅包含您最常访问的数据。拥有 1:1 user_profile 表的一个原因是您只能在用户登录时访问它一次，并且您可能希望缓存该数据，并且只有在用户更新它时才再次检索它。其中很多将取决于您的应用程序本身的使用和架构(即每个应用程序都会有所不同)。
话虽如此，如果您没有大量的列，那么拥有一个表来包含与给定模型相关的所有数据就完全没问题了。
根据您在下面的请求进行更多扩展:我在 SQL 上下文中对元的评论。例如，元数据通常会描述表及其列(即排序规则、字符集、列类型、长度和其他属性等)。从理论上讲，您并没有错误地命名表格，但这可能有点令人困惑。
关于mysql - 什么时候创建元表最好？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48868442/