最近我发现自己为大多数主表创建了元表。
例如 ,我的用户表包含密码、电子邮件和 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/