Таблицы базы данных: один ко многим различных типов

Question

Из-за неразглашения на моей работе я создал аналогию ситуации. Пожалуйста, постарайтесь сосредоточиться на проблеме, а не на «Почему вы не переименуете эту таблицу, не добавите ее в таблицу и т. Д.». Потому что реальная проблема гораздо сложнее.

Вот сделка,

Допустим, у меня есть запись "Повышение зарплаты сотрудника", которая должна быть утверждена.

Есть таблица с одним "Пользователи".

Существуют таблицы, объединяющие пользователей, например, «Менеджеры», «Руководители», «Расчет заработной платы», «Финансы». Эти группировки разных типов с разными свойствами.

При создании записи «PayRise» пользователь, который создает запись, также выбирает как несколько из этих групп (менеджеров, руководителей и т. Д.), Так и / или отдельных пользователей, которые могут «одобрить» повышение заработной платы.

Каков наилучший способ связать одну запись EmployeePayRise с 0 или более записями пользователей и 0 или более каждой из группировок.

Answer 1

Похоже, вам могут понадобиться две таблицы ("ApprovalUsers" и "ApprovalGroups").Операторы SELECT будут СОЮЗОМ UserIds из «ApprovalUsers» и UserID из любых других групп пользователей, которые являются «ApprovalGroups», связанными с PayRiseId.

SELECT UserID
INTO   #TempApprovers
FROM   ApprovalUsers 
WHERE  PayRiseId = 12345

IF EXISTS (SELECT GroupName FROM ApprovalGroups WHERE GroupName = "Executives" and PayRiseId = 12345)
BEGIN
    SELECT UserID
    INTO   #TempApprovers
    FROM   Executives
END

.... 

РЕДАКТИРОВАТЬ: это будет / может дублировать UserIds, поэтому вы, вероятно, захотите, чтобы GROUP BY UserID (т. Е. SELECT UserID FROM #TempApprovers GROUP BY UserID)

Answer 2

Моей первой мыслью было создание таблицы, которая связывает отдельных утверждающих с строками повышения зарплаты.

create table pay_rise_approvers (
  pay_rise_id integer not null references some_other_pay_rise_table (pay_rise_id),
  pay_rise_approver_id integer not null references users (user_id),
  primary key (pay_rise_id, pay_rise_approver_id)
);

Невозможно иметь хорошие внешние ключи, которые иногда ссылаются на менеджеров, и ссылаться на зарплату в других случаях.Пользователи кажутся логической целью для внешнего ключа.

Если человек, создающий строки повышения зарплаты (не показаны), выбирает менеджеров, то пользовательский интерфейс отвечает за вставку одной строки на менеджера в эту таблицу.Эта часть проста.

Человек, который входит в более чем одну группу, может быть проблемой.Я могу представить себе вице-президента, выступающего в группах «Исполнительный» и «Финансовый».Я не думаю, что с этим особенно трудно справиться, но это требует некоторой предусмотрительности.Предположим, что человек, который ввел данные, передумал и решил удалить всех руководителей из таблицы.Должен ли быть удален руководитель, который также работает в сфере финансов?

Другая проблема заключается в том, что существует довольно хороший шанс, что не каждому пользователю будет разрешено одобрить повышение зарплаты.Я бы подумал над этим, прежде чем реализовывать какое-либо решение.

Answer 3

Я знаю, это выглядит некрасиво, но я думаю, что иногда решение может состоять в том, чтобы иметь table_name в таблице и запрос объединения

create table approve_pay_rise (
  rise_proposal varchar2(10)     -- foreign key to payrise table
, approver varchar2(10)          -- key of record in table named in other_table
, other_table varchar2(15) );

insert into approve_pay_rise values ('prop000001', 'e0009999', 'USERS');
insert into approve_pay_rise values ('prop000001', 'm0002200', 'MANAGERS');

Затем либо в коде оператор case, либо повторяющиеся операторы для каждого значения other_table (select ... where other_table = '' .. select ... where other_table = ''), либо выбор объединения.

Я должен признать, что содрогнулся, когда столкнулся с этим, и теперь я пойду вымыть руки после того, как наберу рекомендацию, но это работает.

Answer 4

Я бы предположил, что пользователи связаны с группами? Если это так, в этом случае я бы просто связал запись employeePayRise с одним пользователем, к которому она применяется, и с пользователем, который может утвердить. Таким образом, у вас есть два столбца, представляющих это. Столбцы EmployeePayRise.employeeId и EmployeePayRise.approvalById. Если вам нужно попасть в группы, вы должны присоединиться к записям EmployeePayRise.employeeId = Employee.id. Сохраняйте это простым, не усложняя ваш дизайн.