SunRiderЦель этой затеи:
Прорва ненужного геморроя.

SunRiderА если там достаточно большая иерархия отношений? Т.е. на сотрудника оформлен СПД (субъект предпринимательской деятельности), зарегистрированный во всевозможных администрациях, пенсионных фондах и т.д., у кажого из которых свои реквизиты и куча сопутствующей информации.
И? Правильно ли я понял, что Вы собираетесь на каждого сотрудника вбивать свою запись в таблицы администраций, пенсионных фондов итд?

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

Поймите: кто-то должен принимать ответственные решения. Если человек, который десять лет назад программировал что-то на Клиппере, сейчас сказал Вам - да, и еще наверное надо архив, покумекай на эту тему - это не ответственность, это "благие пожелания", которые сами знаете куда ведут.

SunRiderТ.е. SELECT * FROM Employee
Напугали :)

SunRider1) можно ввести поле isDismissed в таблице Employee, но насколько понизится эффективность запроса SELECT * FROM Employee WHERE isDismissed = false по сравнению с предыдущим запросом?
Зависит от кучи факторов, в том числе от того, в каких попугаях Вы считаете эффективность. В ряде случаев - нинасколько.

SunRider2) Можно сделать отдельную табличку, например, ActualEmployees, в которой просто хранить id работающих сотрудников.
Определенно лишние траты. Зачем делать таблицу там, где достаточно индекса?

SunRiderПредполагается использовать СУБД Oracle 10.x
Честно говоря, вашему руководству стоило бы доверить проектирование базы кому-нибудь, кто хотя бы читал Кайта.

SunRiderЭто я к тому, что запросы могут быть достаточно сложными, на много таблиц и со сложными условиями.
Безусловно. Но на объем данных это влияет крайне мало, страх "десятков тысяч записей" страшнее не выглядит. А в том, что касается сложностей... чем больше у Вас будет "архивных" таблиц, тем больше будет мест, где придется решать, интересуют ли данные из "активной" таблицы, из "архивной" или же из обеих.

SunRiderПочти что так :) А как могло требование создание архива, будучи поставленным изначально, изменить процесс проектирования?
Вопрос не в этом. Просто это было брякнуто из общих соображений, и не следует расценивать это как нечто ценное и тем более как руководство к действию.

Ключевое требование в этой задаче - оно затронуто в Вашем первом письме - это версионность практически всех данных. Люди приходят, уходят и возвращаются; люди меняют должности переходят между отделами; меняется штатное расписание/оргструктура и так далее. Вот над этим надо думать, думать долго и хорошо (а лучше - смотреть готовые решения и потом думать).

SunRiderНу, данных-то может быть много ;)
Сколько?

SunRiderВремя обработки запроса - я о таком "попугае".
Такой запрос скорее всего пойдет в FIRST_ROWS по индексу - брать первые 25-50 записей в соответствии с order by - и лишнего времени не займет.

SunRiderв смысле - индекса?
В смысле. Собственно, смотрите того же Кайта, он пишет много лучше, чем я :)

SunRiderНу не всем же сразу профессионалами быть, надо когда-нибудь и как-нибудь понемногу учиться, правда ж? :)
Правда, хотя учиться эффективнее в команде с более опытными людьми. И Вас, если обратите внимание, никто не упрекает. А вот вашему руководству это действительно минус - если, конечно, система хоть немного нужна :)

DVE
Не очень понимаю, какую мораль можно прочитать по поводу сверхстандартного SCD2.

В Вашем рассказе опущен самый интересный момент. Допустим, Маша работает в отделе АСУ, который с 01.01.2002 называется департаментом ИТ. Это переименование не должно требовать глобального изменения данных сотрудников - для чего Маша должна ссылаться не на версию отдела АСУ, а на отдел в целом, на стержневой идентификатор....