Управление версиями в таблицах SQL - как с этим справиться?

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

TABLE EMPLOYEE: (with personal commentary)

|ID | VERSION | NAME       | Position | PAY |
+---+---------+------------+----------+-----+
| 1 |    1    | John Doe   | Owner    | 100 | Started company
| 1 |    2    | John Doe   | Owner    |  80 | Pay cut to hire a coder
| 2 |    1    | Mark May   | Coder    |  20 | Hire said coder
| 2 |    2    | Mark May   | Coder    |  30 | Productive coder gets raise
| 3 |    1    | Jane Field | Admn Asst|  15 | Need office staff
| 2 |    3    | Mark May   | Coder    |  35 | Productive coder gets raise
| 1 |    3    | John Doe   | Owner    | 120 | Sales = profit for owner!
| 3 |    2    | Jane Field | Admn Asst|  20 | Raise for office staff
| 4 |    1    | Cody Munn  | Coder    |  20 | Hire another coder
| 4 |    2    | Cody Munn  | Coder    |  25 | Give that coder raise
| 3 |    3    | Jane Munn  | Admn Asst|  20 | Jane marries Cody <3
| 2 |    4    | Mark May   | Dev Lead |  40 | Promote mark to Dev Lead
| 4 |    3    | Cody Munn  | Coder    |  30 | Give Cody a raise
| 2 |    5    | Mark May   | Retired  |   0 | Mark retires
| 5 |    1    | Joey Trib  | Dev Lead |  40 | Bring outside help for Dev Lead
| 6 |    1    | Hire Meplz | Coder    |  10 | Hire a cheap coder
| 3 |    4    | Jane Munn  | Retired  |   0 | Jane quits
| 7 |    1    | Work Fofre | Admn Asst|  10 | Hire Janes replacement
| 8 |    1    | Fran Hesky | Coder    |  10 | Hire another coder
| 9 |    1    | Deby Olav  | Coder    |  25 | Hire another coder
| 4 |    4    | Cody Munn  | VP Ops   |  80 | Promote Cody
| 9 |    2    | Deby Olav  | VP Ops   |  80 | Cody fails at VP Ops, promote Deby
| 4 |    5    | Cody Munn  | Retired  |   0 | Cody retires in shame
| 5 |    2    | Joey Trib  | Dev Lead |  50 | Give Joey a raise
+---+---------+------------+----------+-----+

Теперь, если бы я хотел сделать что-то вроде «Получить список текущих кодировщиков», я не мог бы просто сделать SELECT * FROM EMPLOYEE WHERE Позиция = "Кодер" , потому что это вернет много исторических данных ... что плохо.

Я ищу хорошие идеи для обработки этого сценария. Я вижу несколько вариантов, которые мне бросаются в глаза, но я уверен, что кто-то скажет: «Вау, это ошибка новичка, светится ... примерьте это для размера:», а это то, о чем все это место, верно? : -)

Идея №1: Сохранять таблицу версий с текущей версией, как это

TABLE EMPLOYEE_VERSION:

|ID |VERSION|
+---+-------+
| 1 |   3   |
| 2 |   5   |
| 3 |   4   |
| 4 |   6   |
| 5 |   2   |
| 6 |   1   |
| 7 |   1   |
| 8 |   1   |
| 9 |   2   |     
+---+-------+

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

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

Накладные расходы, связанные с этим, кажутся нежелательными.

Идея № 2: Храните архивную таблицу и основную таблицу. Перед обновлением основной таблицы вставьте строку, которую я собираюсь перезаписать, в архивную таблицу и используйте основную таблицу, как обычно, как если бы меня не беспокоило управление версиями.

Идея № 3: Найти запрос, который добавляет что-то вроде SELECT * FROM EMPLOYEE WHERE Position = 'Coder' и version = MaxVersionForId (EMPLOYEE.ID) ... Не совсем уверен, как бы я это сделал. Мне это кажется лучшей идеей, но я действительно не уверен на данный момент.

Идея № 4: Создайте столбец для «current» и добавьте «WHERE current = true AND ...»

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

Спасибо!

РЕДАКТИРОВАТЬ 1:

Во-первых, я ценю все ответы, и вы все сказали то же самое thing - DATE лучше, чем НОМЕР ВЕРСИИ . Одна из причин, по которой я выбрал НОМЕР ВЕРСИИ , заключалась в том, чтобы упростить процесс обновления на сервере, чтобы предотвратить следующий сценарий

Человек A загружает запись сотрудника 3 в своем сеансе, и у нее есть версия 4. Человек B загружает запись сотрудника 3 в свой сеанс, и она имеет версию 4. Человек А вносит изменения и фиксирует. Это работает, потому что самая последняя версия в базе данных - 4. Сейчас 5. Человек B вносит изменения и фиксирует. Это не удается, потому что самая последняя версия - 5, а его - 4.

Как шаблон ЭФФЕКТИВНАЯ ДАТА решит эту проблему?

РЕДАКТИРОВАТЬ 2:

Думаю, я мог бы сделать это, делать что-то вроде этого: Человек А загружает запись сотрудника 3 в своем сеансе, и ее дата вступления в силу - 1-1-2010, 13:00, без всякого раздражения. Человек Б загружает запись сотрудника 3 в своем сеансе, и ее дата вступления в силу - 1-1-2010, 13:00, без всякого раздражения. Человек А вносит изменения и фиксирует. Старая копия отправляется в архивную таблицу (в основном идея 2) с датой начала работы 22.09.2010 13:00. Обновленная версия основной таблицы действует с 22.09.2010 13:00. Человек B вносит изменения и фиксирует. Фиксация не выполняется, потому что даты вступления в силу (в базе данных и сеансе) не совпадают.