我们开发了一个基于每个实例配置运行多个实例的系统。
在配置中,您可以定义应该为实例使用哪个设计,组应该有权访问系统等。
实例(我们称之为 sites )由URL
区分e.g。
我检查用户正在访问的当前URL,并知道我应该为实例使用哪种配置(设计,组)。
用户可以访问多个实例。这由用户关联的组进行检查,并通过检查其中一个组是否有权访问此实例( site )。
这已经设计好了。
但是现在我user_setting
每个实例也应该更改( site )
网站A的用户拥有与网站B的同一用户不同的国家,组织,标题等(不幸的是,即使这看起来不合逻辑,也是如此)。
因此,我创建了一个名为user_settings
的表,它存储了所有这些信息,并具有site
的外键。但是这个表会随着时间的推移而水平增长,因为我无法判断上面提到的列是否是我在这个表中唯一需要的列。最终,我们必须添加100个属性,以便在每个站点的基础上进行更改。
可能有更好的方法来设计它吗?
如果我进一步规范化这个设计,我不确定是否会遇到问题。例如创建一个表格(绿色图像)。
请参阅图片以获得更好的可视化效果:
有人有这方面的经历吗?建议非常受欢迎......
答案 0 :(得分:1)
您正在考虑的表格(图表中为绿色)使用的方法称为实体属性值(EAV)。 EAV通常被认为是一种反模式。
你可以找到许多关于使用谷歌的EAV邪恶的咆哮。我个人认为EAV有一个地方,用户设置可能就是其中之一。
但是,在决定之前,你应该先阅读EAV的缺点。
在我看来,拥有一个非常宽的设置表并不会那么糟糕,特别是如果大多数用户将为大多数设置设置值。