管理员和员工具有类似角色时的数据库设计，但管理员可以看到所有其他员工数据

我们正在构建一个具有管理员和员工概念的系统。所以基本上Admin是一个拥有所有权力的员工，可以查看其他员工创建的所有数据。管理员和员工具有类似角色时的数据库设计，但管理员可以看到所有其他员工数据

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

还有其他表我认为这里不需要的角色和EmployeeRoles。

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

我们首先需要查询Employee表发现，供应商的所有员工（我们将有存储在会话时，管理员/员工登录该VENDOR_ID）
然后查询与在从步骤EMPLOYEE_ID阵列1

这是一个不错的方法操作表？

方法2：或在操作表，我将存储VENDOR_ID每个记录（主要是这一切的努力，只有这样，当在我管理日志可以很容易地检索所有的记录而对供应商在从管理日志英寸我可以很容易地找到Vendor_Id并查询动作表

我不知道在这个时刻哪个更好的方法有什么建议像动作一样，还有其他3个表格，其中有类似的概念需要

编辑1：可能有一种情况，我们可以有多个供应商在单一品牌下注册（futur e扩展名），超级管理员希望分析多个分支机构的数据。

来源

2017-12-18 j10

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

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

因此，您必须比较读取查询的写入查询量。如果读取查询太高，那么再次查询。但我想在一个小规模的组织里只有1-2个管理员。我会和Ist一起去，直到遇到一些严重的性能问题。

来源

2017-12-18 14:05:25 DecoderReloaded

谢谢。我想到类似的东西来缓存或存储会话中的员工细节。所以我们使用动作分页 - 你不觉得这将是一个昂贵的查询吗？对于第二种解决方案 - 我想不出映射会改变的场景。我们可以使用主动标志来最大限度地禁用员工。你认为第二种解决方案将缓解查询部分，因为Vendor_Ids的存在，虽然它也可能导致更多的字节 – j10

你可以检查问题中的编辑。如果我们有多个供应商在一个大型组织中注册，那么运行类似的查询就会变成这样：当超级管理员登录时 - 找到与其相关的所有供应商 - 为每个供应商查找所有员工，并像构建数组一样 - > now when你想查询你可以使用where子句（但是员工ID列表将会太大） – j10

如果你使用了正确的索引。查询结构和分页，我不会花费很多时间*。无论如何，将来如果你有多个管理员并且这些类型的读取查询增加了，你可以将具有'vendor_id'，'org_id'的'Action'表格去规范化。但要注意上面提到的一致性和其他问题。 – DecoderReloaded

您可以坚持解决方案1.通过雇员表中的供应商ID索引，您应该对带有动作表的内部联接很好（除非您计划在表中有数百万行并朝向具有单位数毫秒级别的性能）

来源

2017-12-18 19:42:06 user9115075

我会更新这个更清楚地说明有什么替代方案以及如何获得性能。 – kwelch

管理员和员工具有类似角色时的数据库设计，但管理员可以看到所有其他员工数据

回答

相关问题