Создаю хранилище данных. В качестве ключа почти везде будет выступать сотрудник (employee), который генерирует определнную активность. У сотрудника есть следующие поля, которые могут идентифицировать его (причем в разных базах данных эти поля разные): имя, имя аккаунта, номер телефона, менеджер. Каждый из этих аттрибутов важен и нужно отслеживать его изменение.
Например, у человека был менеджер A, а в момент времени T изменился на B. Если мы захотим посмотреть историю работы относительно сотрудника, то кто является менеджером нас не волнует. Но если менеджер B будет смотреть исторические показатели своей команды, то до момента времени T рассматриваемый сотрудник не должен попасть в выборку, а после T должен. Ну и аналогично по все остальным параметрам (у человека может смениться номер телефона, но это все тот же человек; у человека может смениться фамилия и т.д.).
Я не могу сообразить каким образом мне спроектировать соответствующие таблицу. Пока что пришел к следующему варианту:
Identity (id PK) — это просто фиктивная таблица с одним полем — ключом, по которому мы будем связывать исторические данные. Других постоянных данных сотрудник просто не имеет.
Employees (id PK; identity_id FK REF Identity.id; name; username; phone; manager_id FK REF Employees.id, start_date DATETIME; end_date DATETIME).
Теперь пример двух записей из таблицы Employees:
То есть за 4 года у Ирины:
1) Поменялась фамилия с Ivanova на Petrova
2) Поменялся аккаунт c SPBIVANOI на MONPEROI (он не просто генерируется из фамилия + имя, правило другое)
3) Поменялся телефон с 1111111 на 2222222
4) Поменялся менеджер с 51 на 42
В общем поменялось все.
Однако Employees хранит всю историю этих изменений и при необходимсоти мы можем отследить все изменения через identity_id (второй столбец, значение = 3).
Подскажите пожалуйста имеет ли такая идея право на существование? Есть ли более правильные/оптимальные способы хранения высоковолатильной мастер даты в хранилище?