什么时候最好创建元表？

Posted 2023-03-15

【中文标题】什么时候最好创建元表？

【英文标题】：When is it best to create a meta table?

【发布时间】：2018-07-29 19:44:22

【问题描述】：

最近我发现自己为我的大多数主表创建了元表。

例如，我的用户表包含密码、电子邮件和 ID，以及一些时间戳。但是像用户来自哪里，他们的头像，或者他们最喜欢的颜色，我存储在 user_meta 表中。一些详细信息，例如联系人，我在元表中存储为 JSON 值（数组），键为 contacts，值是包含联系人详细信息的 JSON 数组。

我的理由是，它使我可以更轻松地更改前端并添加功能/细节，而不必玩弄服务器端的东西。

话虽如此，我担心我必须经常获取元表，这会影响性能。在上述情况下，每次显示用户列表时，我都必须获取元表，以便获取他们的个人资料图片。

什么时候最好创建一个单独的键值元表而不是只使用特定的列？

【问题讨论】：

我会将个人资料图片、喜欢的颜色、位置等存储为users 表中的列。我会不以这种方式存储联系人 - 它们应该是一个单独的表，并且有适当的关系。

【参考方案1】：

您所做的不一定是不正确的，但是，“元”表并不是描述您希望实现的目标的正确方式，在关系方面。

没有什么可以说您不能拥有与用户 1:1 关系的 user_profile 以及具有不同类型关系的其他表 - 例如一对多。

在 JSON 方面：您的用户联系人数据通常不会在结构上发生变化，因此您可以创建一个 1:n 的 user_contacts 表，假设每个用户有一个或多个联系人。我个人也不喜欢用“元”为表添加后缀来表示一些自我引用，因为描述内容可能过于模糊（尤其是如果您还有一个或多个具有 JSON 数据类型的列）。如果结构会经常更改以保证其有用，我会选择 JSON 数据类型。

如果您的用户数据结构经常发生变化，您可能需要考虑使用 NoSQL 数据库，或者您可能有一个“元”表，如您所描述的，其中包含几个 JSON 数据类型，其中的结构该数据是可变的，您不需要经常解压数据，这会很痛苦......

对此进行一点扩展。没有硬性规定，但通常情况下，如果您的表要存储大量行，您可以保持其紧凑并仅包含您最常访问的数据。拥有 1:1 user_profile 表的一个原因是，您只能在用户登录时访问该表一次，并且您可能希望缓存该数据并仅在用户更新时再次检索它。其中大部分将取决于您的应用本身的使用和架构（即每个应用都会有所不同）。

话虽如此，如果您没有大量的列，那么使用一个表来包含与给定模型相关的所有数据是完全可以的。

根据您的以下请求进行更多扩展：我在 SQL 上下文中对元的评论。例如，元数据通常会描述表及其列（即排序规则、字符集、列类型、长度和其他属性等）。从理论上讲，您并没有错误地命名表，但可能会有点混乱。

【讨论】：

非常彻底的答案！真的，我担心 User_profile 表中有太多行会影响性能。我现在看到了如何将联系人存储在单独的表中。我认为你是对的，这是 NoSQL 的一个很好的用例，但出于某种原因，我很难理解。作为旁注，您能否详细说明何时将“元”一词用于与数据库相关的情况？

@Michał Facebook 在 mysql 中存储了数十亿行。只要你有正确的索引，有很多行应该不是问题。

@ceejayoz 这让我想到他们可以很容易地在我们身上创建一个新的数据字段以显示在用户配置文件的前端。假设他们想将“Favourite Floating Tesla”与“Religious Beliefs”一起显示，这是否是一个简单的案例，只需将新键 favourite_tesla 和值 The red one 添加到预先存在的键值表中，或者是否需要他们添加列和构建新表？

他们在facebook.com/MySQLatFacebook 上有很多有趣的信息。请注意，他们将非 SQL 数据库与 MySQL 结合使用。

【参考方案2】：

什么时候最好创建一个单独的键值元表而不是只使用特定的列？

当应用程序需要执行某些操作的数据类型可能随时间变化，或者当您有大量与模型/表没有强相关性的可空字段时，元表是最佳选择。

WordPress 有一个用于用户和帖子的元表。这是因为 WordPress 被创建为可以通过主题高度自定义，而开发人员不知道每个主题需要什么才能正常运行。

另一个用例可能是，如果您正在创建像 MessageBird 这样的全方位消息传递应用程序，您可以在其中使用 WhatsApp、Telegram 和 SMS 等各种渠道来推送消息。每个通道可能对发送消息所需的数据有不同的要求，未来可能会出现新的通道，并有自己的数据要求。因此，使用元表来满足未来的需求是有意义的。

就影响性能而言，这实际上取决于您的应用程序究竟需要做什么。对于某些用例，性能影响可以忽略不计（例如，如果正在执行的操作仅发生在服务器上并且不需要将数据发送到前端）。但即使不是，您也可以随时使用 Redis 等 NoSQL 服务缓存数据，从而无需在每次请求时从数据库中获取数据。

【讨论】：

直截了当！