|
|
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Добрый день! Нахожусь в процессе проектирования структуры БД, одной из функций которой будет нормирование труда. Есть таблица USERS (Сотрудники), связанная внешним ключом с таблицей DEPARTMENT (Отделы). Есть таблица WORK_QUOTA, которая будет определять норматив чего-либо в штуках (поле WQ_COUNT) и "стоимость выполнения норматива". Нормативы (в порядке приоритета) могут назначаться Отделам и/или персонально Сотрудникам (направление связи пока не придумано). Еще у норматива должен быть период действия. Например, норматив на сборку товара 100 штук в смену, действующий с 01.01.2012 г без указания даты окончания, т.е. своего рода норматив "по умолчанию". Затем вводится срочный норматив на 200 штук в смену со специальной "стоимостью выполнения норматива", который действует в течение недели. После окончания действия срочного норматива снова вступает в силу норматив "по умолчанию". По каждому сотруднику ведется ежедневный учет сборки товара. Структура БД должна позволять получить данные по выполнению нормативов в любой день. Подскажите, в какую сторону двигаться для реализации задуманного? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2012, 19:42 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcello Подскажите, в какую сторону двигаться для реализации задуманного? Отсюда и до обеда http://segfault.kiev.ua/smart-questions-ru.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2012, 22:19 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
SERG1257Отсюда и до обеда http://segfault.kiev.ua/smart-questions-ru.html И к чему эта ссылка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2012, 22:34 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcello И к чему эта ссылка? Задавайте ясные и четкие вопросы Не задавайте вопросы из домашних заданий Если вы не поняли... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2012, 22:49 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
SERG1257А чего бы просто мимо не пройти "отсюда и до обеда", а? Или троллим потихоньку? Если вопрос в первом посте в чем-то непонятен, то могу уточнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2012, 23:17 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
MarcelloПодскажите, в какую сторону двигаться для реализации задуманного? Таблица рабочих дней, содержащая два поля: "норма выработки", "сделано фактически". Заполняется на год вперёд при получении ОК рабочего календаря. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 00:02 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovТаблица рабочих дней, содержащая два поля: "норма выработки", "сделано фактически". Заполняется на год вперёд при получении ОК рабочего календаря. Т.е. при изменении периода действия норматива делать пересчет "норм выработки" в таблице рабочих дней? Вообще такая таблица изначально не рассматривалась, т.к. ежедневный учет сборки товара задуман как вычисляемый на основе накладных, собранных каждым Сотрудником. Т.е. чтобы определить выполнение норматива, выбираем накладные, собранные конкретным Сотрудником в определенный день, затем определяем, какой норматив действовал в этот день. Все это хотелось бы делать одним запросом. Мне кажется, создание дополнительной таблицы приведет к некоей избыточности информации, хотя выборки из такой таблицы будут идти очень быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 01:21 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcello Или троллим потихоньку? Ваша задача очень напоминает тестовое задание для студентов. Marcello Если вопрос в первом посте в чем-то непонятен, то могу уточнитьУточните почему вы не хотите пользоваться стандартным классическим методом сущность связь? Перечислите сущности, обозначьте связи (частично вы это сделали), уткнитесь в проблему: можно сделать так или так, какой из способов лучше и почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 02:30 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcello, На вскидку. Хранение нормативов: Поле ОписаниеВидНорматива Храни ссылку на нормативПодразделение Хранит ссылку на подразделениеНачалоДействия дата начала действия нормативаОкончаниеДействия дата окончания действия нормативовПриоритет Числовое поле. Принимает только положительные целочисленные значения. Необходимо для разрешения конфликтов в случае действия нескольких нормативов в один период.ВидОперации Хранит ссылку на определенную работу/операциюКоличество Нормативное количество История выполнения нормативов: Поле ОписаниеПериод дата выполнения работПодразделение Хранит ссылку на подразделениеСотрудник Хранит ссылку на конкретного сотрудникаВидНорматива Храни ссылку на нормативВидОперации Хранит ссылку на определенную работу/операциюНорма Нормативное количествоФактически Фактическое количество Пояснения: Для получения нужных нормативов делаем запрос по первой таблице с отбором по конкретному подразделению, указав ограничение на окончание действия (чтобы дата окончания была не меньше текущей даты), и получая запись с самым высоким приоритетом. Во вторую таблицу записываем выработку конкретного сотрудника, при этом указываем норматив который он должен был выполнить, нормативную выработку и фактическую выработку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 08:38 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Во главе всего стоит объект. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Идея с приоритетом норматива хорошая, поскольку начало и окончание действия норматива "живут" в OBJECTS. Иначе можно было назначить уникальность по полям WQ_ID_US + WQ_ID_DPT + период действия, чтоб избежать конфликтов без использования приоритета. Повторюсь, заводить отдельную таблицу для выполнения нормативов не хочется, т.к. всю необходимую информацию планируется брать одним запросом. По дате и Сотруднику можно получить собранным им накладные. Но пока непонятно, как в этом же запросе получить норматив, действующий в эту дату, потому что нормативы могут оказаться "вложенными"? Есть ли какие-нибудь идеи по такому запросу? Или это уже выходит за рамки темы "Проектирование БД" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 13:24 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcello Во главе всего стоит объект.Это ваши и только ваши тараканы в голове. Впрочем вреда от этого "общего предка всего сущего" немного (нельзя наложить ограничения внешнего ключа), как впрочем и пользы. Marcello Иначе можно было назначить уникальность по полям WQ_ID_US + WQ_ID_DPT + период действия, чтоб избежать конфликтов без использования приоритета.Нельзя избежать конфликтов, sql не поддерживает ограничения непересекаемости интервалов. Плюс конфликты заложены в условиях задачи. Marcello Повторюсь, заводить отдельную таблицу для выполнения нормативов не хочется, т.к. всю необходимую информацию планируется брать одним запросом.Одним запросом это верно, а вот отдельную таблицу завести придется (на мой взгляд лучше две таблицы нормативы на отдел и нормативы на человека). Marcello действующий с 01.01.2012 г без указания даты окончаниябез указания даты окончания лучше реализовать через дату в будущем типа 01.01.2099 или 01.01.9999, запросы будет писать легче, причем пользователю это можно не показывать. Код: sql 1. Marcello Но пока непонятно, как в этом же запросе получить норматив, действующий в эту дату, потому что нормативы могут оказаться "вложенными"? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Реализация top 1 зависит от вашей субд (limit или rowcount или что там еще) Решение выше это решение задачи "в лоб" - базовое, от которого как от печки надо затем плясать. фактическое выполнение - это совершенно отдельный разговор Marcello По дате и Сотруднику можно получить собранным им накладные.про накладные разговора вообще не было. Александр Пузаков указав ограничение на окончание действия (чтобы дата окончания была не меньше текущей даты)Вы не учитываете изменения в будущем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 18:54 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
SERG1257Впрочем вреда от этого "общего предка всего сущего" немного (нельзя наложить ограничения внешнего ключа), как впрочем и пользы.Внешние ключи в таблицах ссылаются на другие таблицы. Через OBJECTS никаких ссылок нет. У всех типов объектов - накладные, сотрудники, отделы и т.д. и т.п. - есть одинаковые свойства и признаки видимости, активности, блокированности и др., что следует из спойлера 12490269 . Не вижу смысла дублировать эти свойства в каждую таблицу, если все они имеют одинаковое назначение. Кроме того, изменения во всех таблицах будут инициировать изменения в объектах, что будет использоваться для сбора имененной и удаленной информации для последующей передачи между серверами. Про это я не писал в первом посте, потому что к вопросу нормирования труда это не имеет никакого отношения. SERG1257Реализация top 1 зависит от вашей субд (limit или rowcount или что там еще)СУБД FireBird 2.5 или Oracle. Еще нет окончательного решения. Далее вопрос по запросу: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Допустим, есть норматив "по умолчанию" (1) с 01.01.2012 до 01.01.9999. Есть "квартальный" норматив (2) с 01.04.2012 по 30.06.2012. И есть какой-то особый норматив (3) с 25.04.2012 по 30.04.2012. Чтобы запрос вернул правильный норматив (3) без учета приоритета, нужно написать вот так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 19:26 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcello Верно? Нет. Ваш запрос вернет самую раннюю запись (которой скорее всего будет норматив по умолчанию) плюс у вас в датасете будут записи нормативов на отдел и нормативов на человека. Их тоже надо сортировать. В любом случае это вопрос к вашим постановщикам/аналитикам/специалисту_от_бизнеса - описать внятный алгоритм приоритетов. Например: нормативы на человека (если они есть) всегда выше чем нормативы на отдел, из всех вложенных нормативов приоритетным считается самый последний принятый, в случае нескольких принятых одновременно, приоритет у того, который заканчивается раньше. тогда ваш запрос будет Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 20:09 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
SERG1257Александр Пузаков указав ограничение на окончание действия (чтобы дата окончания была не меньше текущей даты)Вы не учитываете изменения в будущем. Т.е. при изменении "старого" норматива в будущем все отработанное ранее должно пересчитаться? Это вообще как-то не спортивно получается... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 20:13 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Я имел ввиду Александр Пузаков указав ограничение на окончание действия (чтобы дата окончания была не меньше текущей даты)плюс ограничение на начало действия чтобы дата начала была не позднее текущей даты. Тогда можно добавить норматив сейчас чтобы он действовал в будущем, например на следующий месяц и не попадался в выборки в этом месяце. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 20:40 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
SERG1257запрос вернет самую раннюю запись (которой скорее всего будет норматив по умолчанию)Действительно. Перепутал сортировки. Потом сюда добавлю фактическое выполнение норматива по накладным, собранным Сотрудником в определенную дату, и получается, что можно обойтись без дополнительных таблиц план-факт. Александр ПузаковТ.е. при изменении "старого" норматива в будущем все отработанное ранее должно пересчитаться?Да, так и есть. Но пересчитается не все, а только то, что попадает в период измененного норматива. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 20:52 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Marcelloпересчитается не все, а только то, что попадает в период измененного норматива. Т.е. человек старается, вкалывает, а потом приходит за зарплатой, а ему - хрен с маслом. Мы, видите ли, нормативы задним числом пересчитали чтобы ФЗП сэкономить... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 21:06 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovТ.е. человек старается, вкалывает, а потом приходит за зарплатой, а ему - хрен с маслом. Мы, видите ли, нормативы задним числом пересчитали чтобы ФЗП сэкономить...Давайте не будем отвлекаться от темы. Норматив вполне мог быть выставлен с ошибкой. Такое же возможно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 21:37 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
MarcelloТакое же возможно? Нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 21:42 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovMarcelloТакое же возможно? Нет. Назначили новый норматив с 1 числа следующего месяца. А 2 числа увидели заметное снижение выполнения плана от среднего значения. Выяснилось, что норму выставили больше нужного на 25%. При среднем выполнении плана 90% вряд ли кто-то сможет выполнить ошибочно выставленный норматив даже на 75%. Предлагаете оставить норматив как есть и не менять до следующего месяца? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 22:49 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
MarcelloПредлагаете оставить норматив как есть и не менять до следующего месяца? Почему "до следующего месяца"? Уже третьего числа новый тариф можно ввести в силу. А если "заметили" только через полгода, то Вы предлагаете пересчитать всё на полгода назад?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2012, 23:08 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovУже третьего числа новый тариф можно ввести в силу.А первое и второе число по Вашей логике оставляем с ошибочным нормативом? Дмитрий, давайте не будем уходить от темы. Вопрос был не по нормированию труда, а по реализации структуры БД. Ответы на этот вопрос в теме даны. Спасибо всем за участие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2012, 01:32 |
|
||
|
Структура БД для нормирования труда
|
|||
|---|---|---|---|
|
#18+
SERG1257Я имел ввиду Александр Пузаков указав ограничение на окончание действия (чтобы дата окончания была не меньше текущей даты)плюс ограничение на начало действия чтобы дата начала была не позднее текущей даты. Тогда можно добавить норматив сейчас чтобы он действовал в будущем, например на следующий месяц и не попадался в выборки в этом месяце. А, ну это да :) Упустил из виду... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2012, 06:55 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37777797&tid=1541706]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
140ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 477ms |

| 0 / 0 |
