|
|
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
Привет всем.. посоветуйте пожалуста как лучше реализовать такую вот структурку.. Есть к примеру пользователь, который принадлежит к департаменту, каждому департаменту соотвествует свой перечень вопросов.. (все это реализовала).. но данный пользователь может перейти в другой департамент, соответственно перечень его вопросов изменится.. если просто в той же таблице менять ид_департамента, получается в хистори мы не увидим его к примеру списке пользователей департамента А если он перешел в департамент Б на определенную дату.. когда он еще был в департаменте А... Как лучше это реализовать?... Спасибо.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2008, 11:05 |
|
||
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
Т.к. для пользователя нужно вести историю, то в таблице "Пользователь" надо: 1) создать еще одно поле, например, effective_date, и в качестве первичного ключа сделать 2 поля id_пользователя и effective_date (т.е. первичный ключ будет составной). или 2) создать еще 2 поле, например, effective_date_start и effective_date_end, и в качестве первичного ключа сделать 3 поля id_пользователя, effective_date_start и effective_date_end (первичный ключ тоже будет составной). Это позволит отслеживать все изменения с пользователем, с какой даты и по какую он числился в таком-то департаменте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2008, 12:13 |
|
||
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
Перевод пользователя из департамета в департамент осуществляется, скорее всего, приказом руководства. Добавляем новую сущность, например TRANSFER_ORDER, с минимальным набором полей ID_customer, ID_department, transfer_date, leave_date, где ID_customer - ну понятно, пользователь; ID_department - департамент, в который пользователь переведен; transfer_date - дата перевода в данный департамент; leave_date - дата ухода из данного департамента. Для актуальной записи leave_date = NULL. Тогда при получении списка пользователей в заданном департаменте на определенную дату запрос можно сформировать примерно так : Код: plaintext 1. 2. Немного не по теме - 'agreement' без t - наверно, опечатка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2008, 12:18 |
|
||
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
А если к примеру создать еще одну таблицу в которой будет только: ид юзера дата начала дата окончания ид департамента.. Что скажете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2008, 15:49 |
|
||
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
Приветик всем.. вопрос немного усложнился... тоесть раньше было хистори только о переводе сотрудника из подразделения в подразделение, теперь стоит вопрос о том, что фамилия сотрудника может изменяться, так же названия департаментов могут меняться... но при этом необходимо учесть что при выгрузке информации до смены названия название должно быть одно - после другое... или если же берется инфа за общий период то должна подгружатся вся информация и та что до перейменования и та что после.. помогите в целом разобраться с такими вот архивами.. как их лучше хранить и как лучше строить базу для таких случаев. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2008, 13:12 |
|
||
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
Самый простой путь, но довольно неправильный - добавить в справочник департаментов и сотрудников поле даты по которую активна данная запись. И в запросах всюду добавить проверку на эту дату. Можно добавить два поля - дата с какой запись активна, и дата по какую запись активна. Тогда запросы на выборку будут еще проще - нужная дата в промежутке этих дат (BETWEEN). Чуть усложнится добавление записей, так как надо будет модифицировать конечную дату у имеющейся записи и ставить начальнкую дату у добавляемой записи больше предыдущей конечной, но это не слишком сложно. В этому случае, если фамилия или название департамента поменялось - у текущей записи ставите конечную дату, а новую запись заводите с новой датой и измененными реквизитами. Но возникает вопрос с ID сотрудников и депратаментов. Если они у вас определены как уникальные ключи, и нужно иметь возможность получить по сотруднику полную выборку по его одному ID, то тогда имеет смысл вынести все изменяемые реквизиты в отдельные таблицы, и уже там делать хранение по времени. То есть в сотруднике у вас будет только неизменяемая информация, например ID, а уже фамилия, имя и отчество - хранится в отдельной таблице, с дополнительными полями дат. Запросы усложнятся к таблице сотрудников усложнять на лишний join, но зато можно будет вводить планируемые переименования, будущей датой. Ну и, опять же, для запросов на текущую дату, к примеру, можно предопределенные view использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2008, 13:58 |
|
||
|
Вопрос по структуре.
|
|||
|---|---|---|---|
|
#18+
названия департаментов могут меняться Я бы советовала вынести в таблице DEPARTMENTS хранить актуальное название департамента, а историю переименований вынести в отдельную таблицу. Поля у этой таблицы будут примерно такие - id, id_dep, old_name, deactivate_date (дата вывода такого названия из обращения) А с сотрудниками - надо сразу возможно точнее определить, какие данные вам требуется по ним хранить. Если уж дошло до перемены имени - тогда и паспортные данные наверняка понадобятся. А на следующий день - адрес (фактический и регистрации). И т.д. В любом случае из c_custom фио лучше вынести. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2008, 15:35 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35354062&tid=1543839]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
140ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 422ms |

| 0 / 0 |
