当管理员和员工具有相似角色时的数据库设计，除了管理员可以看到所有其他员工数据答案

【问题标题】：Database Design when Admin and Employee have similar roles except Admin can see all the other Employees Data当管理员和员工具有相似角色时的数据库设计，除了管理员可以看到所有其他员工数据
【发布时间】：2017-12-19 13:31:15
【问题描述】：

我们正在构建一个具有管理员和员工概念的系统。所以基本上管理员是一个拥有所有权力的员工，可以查看其他员工创建的所有数据。

CREATE TABLE `Vendor` (
  `vendor_Id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(40) NOT NULL,
  `email_Id` varchar(40) DEFAULT NULL,
  `landline_Number` varchar(15) DEFAULT NULL,
  `mobile_Number` varchar(15) DEFAULT NULL,
  `address_Line1` varchar(65) NOT NULL,
  `address_Line2` varchar(65) DEFAULT NULL,
  `city` varchar(255) NOT NULL,
  `pincode` int(6) NOT NULL,
  `country` varchar(255) NOT NULL,
  PRIMARY KEY (`vendor_Id`),
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=latin1

CREATE TABLE `Employee` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `vendor_Id` int(10) unsigned DEFAULT NULL,
  `name` varchar(40) NOT NULL,
  `username` varchar(40) DEFAULT NULL,
  `password` varchar(255) DEFAULT NULL,
  `role` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `employee_username_unique` (`username`),
  KEY `employee_vendor_id_foreign` (`vendor_Id`),
  CONSTRAINT `employee_vendor_id_foreign` FOREIGN KEY (`vendor_Id`) REFERENCES `Vendor` (`vendor_Id`)
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=latin1


CREATE TABLE `Action` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `emp_Id` int(10) unsigned DEFAULT NULL,
  `name` varchar(60) NOT NULL,
  `assigned_To` varchar(40) DEFAULT NULL,
  `deadline` datetime(3) NOT NULL,
  `notes` varchar(400) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `action_emp_id_foreign` (`emp_Id`),
  CONSTRAINT `action_emp_id_foreign` FOREIGN KEY (`emp_Id`) REFERENCES `Employee` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=latin1

我认为这里不需要其他表 Roles 和 EmployeeRoles。

方法一：现在，当管理员登录查看每个人创建的所有操作时

我们首先需要查询 Employee 表以查找该 Vendor 的所有员工（当管理员/员工登录时，我们会将 Vendor_Id 存储在会话中）
然后使用步骤 1 中的employee_Id 数组中的 where 查询 Action 表

这是一个好方法吗？

方法 2 ：或者在 Action 表中，我将为每条记录存储 Vendor_Id（主要是所有这些工作，以便在管理员登录时我可以轻松检索该供应商的所有记录。当管理员从 session 登录我可以轻松找到 Vendor_Id 并查询 Action 表。

目前我不知道哪种方法更好。有什么建议么？与 Action 一样，还有其他 3 个表需要应用类似的概念。

编辑 1：可能会有多个供应商在一个品牌下注册（未来扩展），并且超级管理员想要跨多个分支机构分析数据。

【问题讨论】：

标签： mysql database database-design

【解决方案1】：

第一种方法是基本的标准化方法。当您将vendor_id 放入会话时，您还可以将员工数组（具有属于该供应商的emp_ids）放入会话或缓存中。在这里您不必一次又一次地查询，因为它会在会话或缓存到期时刷新。

第二种解决方案是非规范化的解决方案。在这里，您会遇到基于一致性的问题。在更新每个 vendor_id-emp_id 映射时，您也需要更新您的操作表。

因此，您必须将写入查询的数量与读取查询的数量进行比较。如果读取查询太高，则选择第二个。但我想在一个小型组织中只有 1-2 名管理员。在遇到一些严重的性能问题之前，我会选择 Ist。

【讨论】：

谢谢。我想到了在会话中缓存或存储员工详细信息的类似方法。所以我们对 Actions 使用分页 - 你不觉得这将是一个昂贵的查询吗？对于第二种解决方案 - 我想不出映射会改变的场景。我们可以使用活动标志来最大程度地禁用员工。您是否认为第二种解决方案会因为 Vendor_Ids 的存在而简化查询部分，尽管它也可能导致更多字节
你能检查问题中的编辑吗？当我们在一个大组织下注册了多个供应商时，运行类似的查询会变成这样：当超级管理员登录时 - 找到与之相关的所有供应商 - 找到每个供应商的所有员工并像构建一个数组 - > 现在什么时候你想查询可以使用 where 子句（但是员工 id 列表会太大）
如果您使用了正确的索引。查询结构和分页，我不认为它会花费很多时间。无论如何，将来如果您有多个管理员并且此类读取查询增加，您可以将包含 vendor_id、org_id 的 Action 表非规范化到其中。但请注意我上面提到的一致性和其他问题。

【解决方案2】：

您可以坚持解决方案 1。在员工表中的供应商 ID 上有一个索引，您应该擅长与操作表进行内部联接。（除非您计划在表中拥有数百万行并希望拥有个位数毫秒级别的性能）

【讨论】：

我会更新它，以更明确地说明有哪些替代方案以及如何获得性能。