Вопрос моделирования: списки, которые зависят друг от друга, но могут быть специализированными записями? - PullRequest
0 голосов
/ 23 мая 2009

Поверьте мне, я много думал об этой проблеме, прежде чем спрашивать здесь, и я думаю, что нашел решение, но я хотел бы посмотреть, что вы, ребята, можете придумать, прежде чем согласиться на мое собственное :)

СЦЕНАРИЙ:

В домене мы получили 3 объекта: лечение, косметический салон и сотрудник. Магазин красоты может нанять 0 для многих сотрудников. Теперь у косметолога есть список возможных процедур, которые он может сделать для своих клиентов. Каждое лечение имеет описание, продолжительность и цену. У каждого сотрудника есть подобный список, но каждый сотрудник может специализировать каждую процедуру (разную цену или продолжительность), добавлять новые процедуры или «удалять» процедуры, полученные из косметического магазина.

.. Мне кажется, это довольно распространенная проблема, поэтому я надеялся, что кто-нибудь может придумать что-нибудь умное:)

Пока что я думаю о том, чтобы каждая процедура имела уникальный идентификатор, а затем позволила сотруднику в списке вставлять процедуры, которые будут иметь тот же идентификатор, что и в магазине. Затем эти процедуры для сотрудников переопределяют магазинные с тем же идентификатором.

Заранее спасибо

Ответы [ 3 ]

2 голосов
/ 23 мая 2009

Мы говорим об объективном представлении проблемы или о представлении проблемы в базе данных? Если это объективное представление, то специализированный режим должен быть просто подклассом родового режима.

С представлением проблемы в реляционной базе данных все становится немного сложнее:

beautyshop ---= employee
beautyshop ---= treatment_type
treatment_type ---= treatment
employee =--= treatment

(---= - это один ко многим, =--= - это много ко многим).

Но как нам получить список процедур, доступных в косметичке? Мы не делаем. Вместо этого мы получаем список процедур, доступных от всех сотрудников beautyshop. Тем не менее, если в beautyshop работает 0 сотрудников, он не обслуживается.

Вы можете использовать пустые поля в таблице treatment, чтобы указать, что конкретный сотрудник выполняет эту процедуру со свойствами по умолчанию. Если значения default_type для конкретного beautyshop меняются, все процедуры обновляются.

1 голос
/ 23 мая 2009

Я бы предложил добавить какой-то механизм наследования / специализации в Treatments, добавив ссылку parentTreatment в класс Treatment. У вас будет набор стандартных Treatments, и каждый Employee сможет выбрать и настроить их. BeautySalon s не будет явно хранить какой-либо Treatments, временный и изменчивый метод getAvailableTreatments() будет перебирать связанный Employees и агрегировать родительский Treatments Treatments, предлагаемый каждым Employee.

0 голосов
/ 23 мая 2009

Почему вы хотите проходить разные процедуры с одним и тем же идентификатором?

Я бы предпочел установить идентификатор "пользовательского режима".

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...