具有不同角色的用户的最佳表结构

Question

我们正在开发一个网站，该网站将包含大约5个不同的用户角色，每个角色都有不同的属性。在当前版本的数据库模式中，我们有一个用户表，它包含所有用户及其所有属性。

问题是我们需要的属性因用户角色而异。所有用户都具有相同的基本属性，如名称，电子邮件地址和密码。但最重要的是，每个角色的属性不同。一些有社交媒体链接，另一些有发票地址等。总共最多可以有60列（属性），其中每个用户角色只使用一部分。

总共我们可能在表中有大约250,000个用户，其中最大部分（约220,000）将是单个用户角色（并且使用60个列中的大约20个）。其他30,000个用户分为四个其他规则，并使用其他40个列的子集。

从数据库作为开发角度来看，最好的数据库结构是什么？我的想法是拥有一个基本用户表，然后使用用户 _ 主持人这样的表进行扩展，但这可能会导致很多JOIN查询。防止这种情况的一种方法是使用VIEW，但我已经阅读了一些VIEW可能会影响性能的（过时的）文章，例如：http://www.mysqlperformanceblog.com/2007/08/12/mysql-view-as-performance-troublemaker/。

＆＃39>完美＆＃39;结构甚至存在？任何建议，或者根本不是这个问题，我们应该把所有用户放在一个大表中吗？

Answer 1

在我看来，这种案件的“完美”结构是党派 - 角色 - 关系模式。搜索Len Silverston关于数据模型的书籍。它在开始时看起来很复杂，但它提供了很大的灵活性......

最大的问题是采用完美解决方案的实用性。除了你之外没有人可以回答这个问题重构永远不是一件容易而快速的任务，所以如果你的项目寿命为1年，花费9个月支付“技术债务”听起来更像浪费时间/努力/等。

至于连接的性能，拥有适当的索引通常可以解决潜在的问题。如果没有，您可以随时实现物化视图;即使mysql没有开箱即用的选项，你可以自己设计并以不同的方式刷新它（例如，定期/按需使用触发器或启动刷新程序）。

Answer 2

有两种不同的方法可以解决这个问题。一种称为“单表继承”。这基本上就是您要求评论的设计。这很快，因为没有连接。但是，NULL可以在很小程度上影响吞吐量，因为胖行比较薄的行需要更长的时间才能进入内存。

另一种设计称为“类表继承”。在这个设计中，有一个表用于超类，一个表用于每个子类。非关键属性进入它们所属的表。通常，这种设计可以使用称为“共享主键”的设计。在共享主键中，子类表的键ID是超类表中相应行的id的副本。

这在插入时有点工作，但是当你加入数据时它会自行付出代价。

你应该在SO中查找所有这三个（他们有自己的标签）或者在网上查找。您将获得有关设计的更多详细信息，并指出每种设计适合您的情况。

Answer 3

table user table roles table permissions table userRole table userPermission table RolesPermissions

每个角色都有角色权限表中的权限 每个用户都可以拥有该角色的权限（extention ...）

所以在PHP中你只需要在用户角色和扩展权限中合并用户权限数组...... 在您的“acl”课程中，您可以检查您的用户是否有权查看或处理网页或系统流程......

Answer 4

我认为你不必在这里担心速度。 因为它只是一次性的事情。即在会话中的用户登录商店acl上，然后从那里获取它。

加入并不是那么糟糕。如果您使用InnoDB引擎将索引和外键放在正确的位置，那么它将非常快。

我会为用户和role_id使用一个表。带角色的第二个表。第三个表用于资源，一个用于将它们连接在一起+启用标志。