Я только что разработал набор таблиц, в котором я придумал архитектуру, которая меня очень порадовала! Я никогда не видел его где-либо еще, поэтому я хотел бы знать, если я только что изобрел колесо (наиболее вероятное), или это подлинное новшество.
Вот формулировка проблемы: у меня есть Employees, каждый из которых может подписать свой контракт с компанией. Каждый сотрудник может выполнять различные действия, и у каждого действия может быть разная ставка оплаты, иногда фиксированная сумма за выполнение одного действия, иногда почасовая ставка, а иногда по многоуровневой ставке. Также может быть конкретный клиент, который особенно любит сотрудника, поэтому, когда он работает с этим конкретным клиентом, он получает более высокую ставку. И если ставка не определена, он получает ставку по умолчанию компании.
Не суетитесь о деталях: суть в том, что существует множество уровней оплаты, которые можно определить, причем каждый довольно сложным образом. И все ставки заработной платы имеют следующие общие черты:
- Тип услуги
- Тип шкалы оплаты (Перечисление: фиксированная сумма / Почасовая ставка / Уровень многоуровневой)
- Фиксированная сумма (если PayScaleType = FA)
- Почасовая ставка (если PayScaleType = HR) - да, может быть объединена в одно поле, но по причинам, которые я здесь не буду описывать, я их разделила
- Уровни (1-> n отношений, со всеми уровнями и суммой, которую нужно заплатить, когда вы превысите пороговое значение уровня)
Данные ставки применяются к:
- ставка по умолчанию для компании
- Рейтинг сотрудников
- Коэффициент отмены сотрудника (определяется для каждого клиента)
Если бы мне пришлось следовать простому подходу грубой силы, мне пришлось бы создать таблицу клонов PayRate и PayRateTier для каждой из трех таблиц выше, а также соответствующие им классы Linq, а также логику для расчета ставок в 3 отдельных места, как-то рефакторинг для повторного использования логики расчета. Тьфу. Это похоже на использование копирования и вставки только в базе данных.
Итак, что я сделал? Я создал промежуточную таблицу, которую я назвал PayRatePackage, состоящую только из поля идентификатора. У меня есть только одна PayRate таблица с обязательным FK до PayRatePackage и таблица PayRateTier с обязательным FK до PayRate. Затем DefaultCompanyPayRate имеет обязательный FK для PayRatePackage, как и EmployeeRate и EmployeeOverrideRate.
Так просто - и все работает!
(Простите за то, что я не прикреплял диаграммы; это было бы большим усилием, чтобы перейти к такому вопросу, на котором я уже решил основную проблему. Если многие люди хотят видеть диаграмму, скажите, пожалуйста, в комментарии, и я скину что-нибудь вместе.)
Теперь, я почти уверен, что что-то такое простое и эффективное должно быть где-то в официальной схеме проектирования, и я бы хотел знать, что это такое. Или я просто изобрел что-то новое? :)