У нас есть несколько офисов, и в каждом офисе есть несколько отделов (некоторые отделы имеют сотрудников в нескольких офисах). У нас есть две существующие системы, которые идентифицируют сотрудников по-разному: в одной сотрудники идентифицируются IDA; в остальных сотрудники идентифицированы ИБР.
В тех случаях, когда сотрудник идентифицируется IDA, нам необходимо указать руководителя этого сотрудника, если таковой имеется, в SUPERVISOR_IDA.
Моя таблица выглядит так:
IDA
IDB
SUPERVISOR_IDA
OFFICE
DEPARTMENT
Сотрудники могут иметь должности более чем в одном офисе или более чем в одном отделе, поэтому один и тот же IDA или IDB может существовать более одного раза, но с другим офисом, отделом или и тем, и другим.
Проблема в том, что IDA может быть нулевым (и если это так, то IDB не является нулевым) или IDB может быть нулевым (и если это так, то IDA не является нулевым), или оба могут присутствовать.
Я пытаюсь настроить уникальные и/или первичные ключи и ограничения, чтобы обеспечить целостность базы данных.
Поэтому я создал уникальный ключ на (IDA, IDB, OFFICE, DEPARTMENT).
Вот моя проблема:
Мне нужно убедиться, что сотрудники ссылаются на своих руководителей. Я хотел иметь самоссылающийся внешний ключ, чтобы удаление супервизоров не оставляло потерянных записей о сотрудниках, имеющих ненулевой SUPERVISOR_IDA. Но поскольку мне нужно было включить IDB в свой уникальный ключ в этой таблице, если я создам этот внешний ключ, мне нужно будет включить IDB как таковой:
local PARENT_IDA -> reference IDA
local OFFICE -> reference OFFICE
local DEPARTMENT -> reference DEPARTMENT
**local IDB -> reference IDB**
Это проблема, поскольку IDB сотрудника НЕ ДОЛЖЕН совпадать с IDB супервизора.
Я знаю, что кажется, что я пытаюсь сделать слишком много вещей в одной таблице, но на самом деле мою область довольно сложно описать, и поэтому я создал сотрудника/офис/отдел в качестве примера, чтобы проиллюстрировать свои проблемы. Я действительно не могу разделить IDA и IDB на отдельные таблицы, так как они переплетаются некоторыми проблематичными способами, и наличие одного, другого или обоих имеет какое-то важное значение, которое невозможно разделить.
Сначала я хотел настроить уникальный ключ (IDA, OFFICE, DEPARTMENT) в дополнение к вышеупомянутому уникальному ключу, но в отличие от уникальных ключей, состоящих из одного столбца, составные уникальные ключи будут обрабатывать (null, 'A') и (null, 'A') как дубликаты вместо того, чтобы разрешить нулевой столбец, чтобы избежать нарушения ограничения уникальности.
