|
|
|
Связь по дате
|
|||
|---|---|---|---|
|
#18+
Никак не могу доработать схему до конца. Каждый месяц есть определенный набор операций. При этом, у операций есть параметр, который может меняться также каждый месяц. Это таблица OpeartionMonth. То же самое и с сотрудниками (WorkerMonth). Должна быть возможность редактировать доступные операции и доступных сотрудников за каждый месяц, еще не зная, какие операции сопоставлены каждому сотруднику. Далее, нужно поставить в соответствие операции сотрудникам (в пределах месяца). Сейчас это реализовано в таблице DealMonth. Естественно, и операции, и сотрудник должны быть доступны на данный месяц. У меня никак не получается обеспечить выполнение этого требования нормальным образом. В текущем варианте три раза используется поле month_year. Контролировать данные таким образом довольно затруднительно. Хочется, чтобы все обеспечивалось связями. Пробовал создавать отдельную таблицу с месяцами, но тоже ничего особо хорошего не получилось. Каждодневное выполненное количество единиц операции сотрудником хранится в таблице WorkerOperation. Поле month_year там нужно для того, чтобы контролировать значение поля worker_operation_date. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2011, 15:37 |
|
||
|
Связь по дате
|
|||
|---|---|---|---|
|
#18+
InnerCloister, операция не должна знать кто там какие правила понавыдумывал, какая операция доступна в этом месяце и кто как там задним числом доступность операций или менеджеров ковыряет. т.е. ссылка из операций (сделки?) на сочетание [разрешенная операция]<->[разрешенный менеджер] не нужна. ограничение нужно проверять "на входе" в таблицу совершенных операций, т.е. при создании. а дальше она там лежать должна не глядя ни на кого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2011, 21:25 |
|
||
|
Связь по дате
|
|||
|---|---|---|---|
|
#18+
с корабля на ИМХО, не могу согласиться. Нужно иметь возможность получить различную информацию (в т.ч. о доступности операций и сотрудников, в случае как раз-таки занесения информации задним числом, что обязательно будет происходить время от времени) за любой прошедший месяц, а где же еще ее хранить, как не в БД. А операция об этом ничего и не знает, просто на нее ссылается запись из другой таблицы. P.S. решение я для себя нашел, не очень ровное, но цель достигнута. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2011, 09:29 |
|
||
|
Связь по дате
|
|||
|---|---|---|---|
|
#18+
InnerCloister, автора где же еще ее хранить, как не в БД я вас слегка не ферштейн вобще. суть моего предложения: в совершенных операциях не нужно хранить ссылку на правила, по которым она была совершена (доступность менеджеров и операций) вы случае как раз-таки занесения информации задним числом и с чем вы "не можете согласиться"? написали все то же самое... яограничение нужно проверять "на входе" в таблицу совершенных операций, т.е. при создании. а дальше она там лежать должна не глядя ни на кого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2011, 10:10 |
|
||
|
Связь по дате
|
|||
|---|---|---|---|
|
#18+
с корабля на ИМХО, значит, я не понял ваш первый пост. Но вот вы говорите, что в совершенных операциях (WorkerOperation, как я понял) не нужна ссылка на связь между операцией и сотрудником (DealMonth). Но это невозможно, т.к. мне как раз-таки нужно знать, какая операция в каком количестве была совершенна определенным сотрудником за определенное число. У каждой операции своя расценка (operation_rate), которая учитывается при вычислении суммы оплаты труда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2011, 08:56 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1542008]: |
0ms |
get settings: |
12ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
192ms |
get topic data: |
14ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 549ms |

| 0 / 0 |
