Admin과 Employee가 Admin 이외의 유사한 역할을하는 데이터베이스 설계는 다른 모든 Employees 데이터를 볼 수 있습니다

Question

우리는 Admin과 Employee의 개념으로 시스템을 구축하고 있습니다. 기본적으로 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 

여기서 필요하지 않은 Roles 및 EmployeeRoles 테이블이 있습니다.

접근 한 : 관리자 모두에 의해 생성 된 모든 작업을 볼 수에 로그인 할 때 이제

1. 우리가 먼저 해당 공급 업체의 모든 직원을 찾을 수있는 직원 테이블을 쿼리해야 (우리는해야합니다 관리자/직원이 로그인 할 때 세션에 저장된 VENDOR_ID)
2. 는 다음 단계에서 EMPLOYEE_ID 배열에 1

이 좋은 방법입니다 경우에 작업 테이블을 쿼리?

접근법 2 : 또는 작업 테이블에, 나는 각 레코드 (주로이 모든 노력에 대한 VENDOR_ID를 저장해야에만 I에서 관리 로그 쉽게 그 공급 업체에 대한 모든 기록을 검색 할 때 이렇게하면에서의 관리 로그. 세션 I 쉽게 작업 테이블을 VENDOR_ID를 찾아 조회 할 수 있습니다. 나는 더 나은 방법이 될 것입니다 지금이 순간에 알 수없는

를. 어떤 제안? 처럼 액션, 다른 3 개 테이블이 있습니다 유사한 개념은 할 필요가있는 적용됨

편집 1 : 단일 브랜드로 등록 된 여러 공급 업체를 보유 할 수있는 경우가 있습니다 (미래 e 확장) Super Admin은 여러 지점에서 데이터를 분석하려고합니다.

Answer 1

첫 번째 방법은 기본 정규화 방법입니다. vendor_id을 세션에 넣으므로 직원 배열 (해당 공급 업체에 속한 emp_ids)을 세션 또는 캐시에 배치 할 수도 있습니다. 여기서 세션이나 캐시가 만료 될 때 새로 고침되므로 계속 쿼리 할 필요가 없습니다.

두 번째 해결책은 비정규 화 된 해결책입니다. 여기서 일관성에 기반한 문제가 발생합니다. 각 vendor_id-emp_id 매핑의 업데이트시에도 액션 테이블을 업데이트해야합니다.

그래서 쓰기 쿼리의 볼륨을 읽기 쿼리와 비교해야합니다. 읽기 쿼리가 너무 높으면 초로 이동하십시오. 하지만 작은 규모의 조직에 단 1-2 명의 관리자가 있다고 가정합니다. 나는 심각한 성능 문제가 발생할 때까지 Ist와 함께 갈 것입니다.

Answer 2

솔루션 1을 사용할 수 있습니다. 직원 테이블의 Vendor ID에 대한 인덱스를 사용하면 작업 테이블이있는 내부 조인 테이블을 사용할 수 있습니다 (테이블에 수백만 개의 행이있는 것을 고려하지 않는 한 한 자리 밀리 초 수준의 성능 보유)