最近我发现自己为大多数主表创建了元表。
例如,我的用户表包含密码,电子邮件和ID,以及一些时间戳。但是我在user_meta表中存储用户所在的位置,他们的个人资料图片或他们喜欢的颜色。一些细节,例如联系人,我在元表中存储为JSON值(数组),键为contacts
,值为带有联系人详细信息的JSON数组。
我的理由是,它让我更容易更改前端并添加功能/细节,而无需使用服务器端的东西。
话虽如此,我担心我必须经常获取影响性能的元表。在上面概述的情况下,我每次显示用户列表时都必须获取元表,以便我可以获取他们的个人资料图片。
什么时候创建一个单独的键值元表而不是仅使用特定的列?
答案 0 :(得分:1)
你所做的不一定是不正确的,但是,“关系”表中的“元”表并不是描述你想要实现的目标的正确方法。
没有任何迹象表明你不能拥有与用户具有1:1关系的user_profile以及具有不同类型关系的其他表 - 例如一对多。
在JSON方面:您的用户联系人数据通常不会在结构上发生变化,因此您可以创建一个带有1:n的user_contacts表,假设每个用户有一个或多个联系人。我也不会个人喜欢用“meta”后缀表来表示一些自引用,因为它太含糊不清,无法描述可能是什么内容(特别是如果你还有一个或多个具有JSON数据类型的列)。如果结构经常发生变化以保证其有用,我会选择JSON数据类型。
如果用户数据的结构经常变通,你可能想要考虑一个NoSQL数据库,或者你可能有一个单独的“元”表,正如你所描述的那样,有几个JSON数据类型所在的结构这些数据是可以改变的,你不需要经常解压缩数据,因为它很痛苦......
稍微扩展一下。没有硬性规则和快速规则,但通常情况下,如果您的表要存储大量行,您可以将其保持紧凑并仅包含您最常访问的数据。拥有1:1 user_profile表的一个原因是,您只能在用户登录时访问该表,并且您可能希望缓存该数据,并且只有在用户更新时才会再次检索该数据。其中很多都将受到应用程序本身的使用和体系结构的控制(即每个应用程序都会有所不同)。
如果说你没有笨拙的列数,那么让一个表包含给定模型的所有相关数据是完全没问题的。
根据您的请求进行更多扩展re:我在SQL上下文中对meta的评论。例如,元数据通常会描述表及其列(即整理,字符集,列类型,长度和其他属性等)。从理论上讲,你并没有错误地命名表格,但这可能有点令人困惑。
答案 1 :(得分:0)
什么时候创建一个单独的键值元表而不是仅使用特定的列更好?
当应用程序需要执行某些操作的数据类型可能随时间变化或您有大量可空字段且与模型没有强相关性时,元表是最佳选择。
WordPress有一个用于用户和帖子的元表。这是因为WordPress的创建是根据主题进行高度可定制的,并且开发人员不知道每个主题将需要正常运行什么。
另一个用例是,如果要创建像MessageBird这样的全消息应用程序,在该应用程序中,您可以使用各种渠道(如WhatsApp,Telegram和SMS)来推送消息。每个通道可能对发送消息所需的必要数据有不同的要求,将来新的通道可能会出现自己的数据字段要求。因此,使用元表来满足将来的需求将很有意义。
就影响性能而言,这实际上取决于您的应用程序需要做什么。对于某些用例,对性能的影响可以忽略不计(例如,如果正在执行的操作仅在服务器上发生,并且不需要将数据发送到前端)。但是,即使不是这样,您也可以始终使用Redis之类的NoSQL服务来缓存数据,从而无需在每次请求时都从数据库中获取数据。