我的用户是存储在具有doctrine(实现用户界面)的数据库中的实体.我将在我的系统中有5个预定义角色,每个用户可能有多个这些角色.
>创建单独的角色实体,并与用户实体创建多对多关系
> Plus：轻松获得具有特定角色的所有用户
>骗局：资源密集型？ (始终需要双联接才能获得用户的所有角色)
>骗局：不是自我？角色的数量(及其名称)永远不会改变,因此将它作为单独的实体存储在数据库中是否有意义？
>在用户中有一个字段,它是一个排序的,以逗号分隔的角色列表,getRoles()实现为explode(‘,’,this.all_roles)
>另外：计算成本不高
> Con：很难让所有用户都具有特定的角色
> Con：像这样的数据库字段让小猫哭泣(normalizaition和stuff)
>每个角色的用户实体中有5个二进制字段
>另外：计算成本不高
> Plus：轻松获得具有特定角色的所有用户
>骗局：这仍然感觉不太好
实现这个系统最常用的方法是什么？
选项1：关系方式
从纯关系的角度来看,您希望数据库规范化,这将导致您的第一个选项：与您的用户表具有m：n关系的角色的表.这有一些优点：
>嗯,这是人们期望您的数据库工作的方式,因此没有隐藏在您的实体中的功能.
>无法搞砸事情(比如当你有一个varchar字段,并期望它有某种格式,如昏迷分离)
>只有一种方法可以做
关于角色永远不会改变的担忧：存储数据关系不是关于它变化的频率.人们应该永远记住要求的变化.你现在以优化的名义陷入困境的越多,当你需要更多经常变化的角色时,你就会越努力.
当然,您可能会遇到性能问题,尤其是遇到某种急切加载问题或者您没有缓存内容并且必须在每个页面加载时重新加载角色时.但是,关系数据库再次被设计为支持这样的东西,所以这里应该是优化查询的方法.
选项2：黑客攻击
您的第二个选项,只是将所有角色存储到varchar中,在性能方面会更好.只加载一个文本字段,一些PHP处理,你就完成了.另一方面,您可能会遇到几个问题：
>您无法控制varchar字段,因此一个故障脚本可能会损害您的整个应用程序(这非常糟糕,但根据您的项目,如果您是唯一的开发人员而且您知道自己在做什么,那么它可能会很顺利)
>对一个数据集的更新要困难得多,因为您必须提取所有角色,更新相关数据并存储回来
>查询具有特定角色的所有用户要困难得多
>删除角色要困难得多
方案3：务实的解决方案
每个角色有5个布尔值的第三个选项位于中间：没有办法搞砸它,性能应该不是问题.更新很容易,也可以删除角色或添加新角色.很清楚这些领域是做什么的,所以这方面也没有坏处.它会使您的实体和数据库看起来更难看,您也可以在用户模型中使用角色名称,将真/假字段映射到正确的角色名称,这可能有点令人困惑.
结果
考虑到这一点,我会考虑选项1.可以假设性能是一个问题,但除非我证明了这一点,否则我不会考虑这些问题.最后,当你真正遇到真正的性能问题时,你会怎么做？您可以添加一些额外的硬件,优化dbms,优化查询,或者使用具有更多性能构建的dbms(Hello Oracle！).
如果由于角色表证明您的应用程序运行缓慢,您可以随后使用选项3.您只需更改用户实体并拥有一个提取角色的查询,并为每个用户设置正确的true / false组合.如果软件是干净的,这是一个小时的问题,所以现在不需要在性能可能不好的想法上这样做.
