|
|
|
структура таблиц для иерархии подразделений, пользователей, данных
|
|||
|---|---|---|---|
|
#18+
Добрый день! Подскажите, пожалуйста, как лучше организовать структуру для хранения информации о подразделениях организации, пользователях, работающих в этих подразделениях, и данных, разбитым по подразделениям? Структура подразделений - древоводная - филиал -> участок -> отдел Подразделения могут прекращать существование, дробиться, менять подчинение. Могут появляться новые. Пользователь может переходить из одного подразделения в другое. Сейчас есть таблица подразделений Код: plaintext 1. 2. 3. 4. 5. 6. 7. Таблица пользователей: Код: plaintext 1. 2. 3. 4. 5. Есть несколько систем, пользующихся этими 2 справочниками В каждой системе есть таблицы данных data: Код: plaintext 1. 2. 3. 4. 5. Проблема при изменении структуры подразделений: При переводе отдела в div появляется новая запись. Все пользователи и данные привязаны к старой записи. Если перепривязать к новой записи только пользователя, он перестанет видеть записи старого подразделения. Если поменять div_id на новый и в данных, то на предыдущие периоды нельзя будет увидеть состояние данных - данные будут такими, как будто они заносились в новое подразделение. Как сделать так, чтобы можно было видеть данные во всей хронологии? Чтобы пользователь видел за предыдущий период данные старого подразделения, а за новый - только нового. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2010, 11:30 |
|
||
|
структура таблиц для иерархии подразделений, пользователей, данных
|
|||
|---|---|---|---|
|
#18+
Интересная задача, Serge N. Imho два подхода: костыли к старой структуре или новая реализация. В какой степени готовы к редизайну? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2010, 22:13 |
|
||
|
структура таблиц для иерархии подразделений, пользователей, данных
|
|||
|---|---|---|---|
|
#18+
Serge NКак сделать так, чтобы можно было видеть данные во всей хронологии? Чтобы пользователь видел за предыдущий период данные старого подразделения, а за новый - только нового.Явная связь "многие-ко-многим", работник может относится к нескольким подразделением, в общем случае - даже одновременно, и наоборот, в подразделении может быть сколь угодно работников. Стандартный вариант - добавить ещё одну таблицу, связи работников с подразделениями, worker_div(worker_id, div_id) . Доступность данных при таком подходе вычисляется очевидным способом. Поле div_id в таблице worker , разумеется, становится абсолютно излишним. Но это, скорее, паллиатив, чем решение. Если подходить тщательнее, то действительно стоило бы пересмотреть постановку. Есть ощущение непродуманности и некоторых явных искусственных ограничений в схеме данных. Например, "принадлежность" определённых данных только одному подразделению, т.е., ограничение аналогичное "жесткой" привязке работника к одному подразделению, которое Вы теперь вынуждены обходить. В общем случае, распределение доступа пользователя к данным несколько сложнее описанного Вами варианта. И если есть такая возможность, то его стоило бы переосмыслить в сторону большей унификации и гибкости. Начните, например, отсюда , и далее по ссылкам и ключевым словам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2010, 02:36 |
|
||
|
структура таблиц для иерархии подразделений, пользователей, данных
|
|||
|---|---|---|---|
|
#18+
Serge NПроблема при изменении структуры подразделений: При переводе отдела в div появляется новая запись. Все пользователи и данные привязаны к старой записи. Здесь ошибка. Пользователи д.б. привязаны не к записи, а к своему подразделению. Перемещение подразделения не влияет на его состав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2010, 10:23 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36501119&tid=1542822]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
163ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 458ms |

| 0 / 0 |
