|
|
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Есть два объекта: ресурсы (человеческие) и должности. Надо сделать составитель расписаний, интерфейс которого будет как на картинке. Один ресурс может занимать одну или несколько должностей. Ресурс может болеть, быть в отпуске, получать замечания, которые записываются в комментарии. Должность может занимать один ресурс, несколько ресурсов или никто. Пользователь должен видеть все пробелы (когда должность никто не исполняет, например, по причине болезни или в отпуске и без замены), а также все «перекрытия» (когда на одной должности несколько ресурсов). Как это лучше хранить? Вариант 1. Код: sql 1. То есть для каждого периода несколько записей. Комментарии для каждого месяца свои, либо дублируются. Вариант 1. Код: sql 1. Хранятся именно периоды. Комментарии для каждого периода без дублирования информации. Вариант 3. Оба варианта плохие (предложить лучший). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2014, 20:37 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Поскольку Activity не составляют непрерывную последовательность, то хранить Activity лучше по второму варианту, с датой начала и конца у каждой. Кстати, о датах - у вас что, все болеют только с первого числа? А вот комментарии в Activity лепить не надо. Судя по рисунку, комментарии - это вообще отдельная сущность, которая может относиться как раз к тому куску времени и должности, когда эту должность никто не занимал. Так что еще одна таблица: Код: sql 1. В интерфейсе комментарии нагляднее показывать не точечными красными уголками, а легким цветовым выделением диапазона, к которому относится комментарий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 13:18 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
В первом случае контроль целостности данных тривиален, во втором - требует специальных усилий. Запросы "пересечений" и "пропусков" в первом варианте тоже как минимум не сложнее, чем во втором. Обновления, приводящие к обьединению/разбиению "непрерывных" участков - в первом гораздо проще. Во втором варианте имхо только один плюс - простота перехода от помесячного учета к посуточному, если он в будущем понадобится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 13:55 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинВо втором варианте имхо только один плюс - простота перехода от помесячного учета к посуточному, если он в будущем понадобится А какие проблемы при этом переходе у первого варианта? Поменять Month на Date? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 15:38 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherПоскольку Activity не составляют непрерывную последовательность, то хранить Activity лучше по второму варианту, с датой начала и конца у каждой. Кстати, о датах - у вас что, все болеют только с первого числа? Непонятен формат первичной информации, на основании которого организовывается хранение. Есть подозрение, что он ближе к второму варианту :). Вывод: стоит как минимум хранить по-второму варианту. Если есть потребность/полезный выхлоп - задействовать хранение ещё и по 1-му варианту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 15:54 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
АнатоЛойКот МатроскинВо втором варианте имхо только один плюс - простота перехода от помесячного учета к посуточному, если он в будущем понадобится А какие проблемы при этом переходе у первого варианта? Поменять Month на Date? Проблема у первого варианта - возрастание в 30 раз количества записей ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 15:59 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинАнатоЛойпропущено... А какие проблемы при этом переходе у первого варианта? Поменять Month на Date? Проблема у первого варианта - возрастание в 30 раз количества записей ;) Для "составителя расписаний" от ТС - первый вариант не нужен. Не факт, что завтра появится потребитель составленных расписаний самописный "расчёт зароботной платы". Смотри ниже: АнатоЛойЕсли есть потребность/полезный выхлоп - задействовать хранение ещё и по 1-му варианту. 5 лет * 365 дней * 50 должностей * 150 сотрудников = 13 млн. записей. Фигня какая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 17:27 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
АнатоЛойКот Матроскинпропущено... Проблема у первого варианта - возрастание в 30 раз количества записей ;) Для "составителя расписаний" от ТС - первый вариант не нужен. Не понимаю термина "не нужен". Он невозможен при организации данных по первому варианту? Почему? Он неудобен при организации данных по первому варианту? Почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2014, 17:46 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинАнатоЛойпропущено... Для "составителя расписаний" от ТС - первый вариант не нужен. Не понимаю термина "не нужен". Он невозможен при организации данных по первому варианту? Почему? Он неудобен при организации данных по первому варианту? Почему? Да, "не нужен" - это "возможен, но менее эффективен (менее удобен) по сравнению со вторым вариантом". Чем менее удобен? Требует дополнительного преобразования входных данных, при этом никому пока не нужна полученная выгода от преобразования... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2014, 00:00 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
АнатоЛой Чем менее удобен? Требует дополнительного преобразования входных данных, при этом никому пока не нужна полученная выгода от преобразования... 1. "Входные данные" - это, по словам ТС, некий гуй. Мне кажется как минимум неочевидным, что этот гуй внутри обязан быть олрганизован так, что "диапазонные" данные из него получать легче, чем "помесячные". Скажем, если этот гуй - экселевская таблица, то данные там лежат скорее в "помесячном" (поскольку поячеечном) виде. 2. Полученная выгода от преобразования в виде упрощения сохранения целостности даннных - никому не нужна? тоже спорно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2014, 12:01 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинАнатоЛой Чем менее удобен? Требует дополнительного преобразования входных данных, при этом никому пока не нужна полученная выгода от преобразования... 1. "Входные данные" - это, по словам ТС, некий гуй. Мне кажется как минимум неочевидным, что этот гуй внутри обязан быть олрганизован так, что "диапазонные" данные из него получать легче, чем "помесячные". Скажем, если этот гуй - экселевская таблица, то данные там лежат скорее в "помесячном" (поскольку поячеечном) виде. 2. Полученная выгода от преобразования в виде упрощения сохранения целостности даннных - никому не нужна? тоже спорно. Гуй - конечный результат. Целостность входных данных единственно что можно проверять в текущей постановке. Как этому поможет первый вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2014, 19:53 |
|
||
|
Планировка должностей
|
|||
|---|---|---|---|
|
#18+
АнатоЛойКот Матроскинпропущено... 1. "Входные данные" - это, по словам ТС, некий гуй. Мне кажется как минимум неочевидным, что этот гуй внутри обязан быть олрганизован так, что "диапазонные" данные из него получать легче, чем "помесячные". Скажем, если этот гуй - экселевская таблица, то данные там лежат скорее в "помесячном" (поскольку поячеечном) виде. 2. Полученная выгода от преобразования в виде упрощения сохранения целостности даннных - никому не нужна? тоже спорно. Гуй - конечный результат. Целостность входных данных единственно что можно проверять в текущей постановке. Как этому поможет первый вариант? Если гуй - конечный результат, то что такое тогда "входные данные" и где ТС пишет о том,в каком формате они есть? Целостность входных данных - например, невозможность назначить одну должность одному исполнителю неколько раз за один и тот же период. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 11:55 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=28&tid=1540852]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 139ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
