管理員和員工具有類似角色時的數據庫設計，但管理員可以看到所有其他員工數據

我們正在構建一個具有管理員和員工概念的系統。所以基本上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

管理員和員工具有類似角色時的數據庫設計，但管理員可以看到所有其他員工數據

回答

相關問題