|
|
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
Вроде все понимаю, не хватает толчка. Задача: существуют услуги, каждая из которых может оказываться по отдельности или входить в состав другой услуги. Кроме того, ко многим услугам надо бы пришпилить описание из нескольких атрибутов кроме обычного количества. А цена как раз зависит от этих атрибутов. Вот это описание я и не знаю куда приложить. Да, и еще, заказчик может заказать одну услугу (отдельную или составную) или несколько (куда могут входить и отдельные и составные).Я составил предварительную схему, но чувствую ерунда какая то получается. Таблицы: Заказчик (CustomerID,...) Заказ (OrderID, CustomerID,...) Список услуг в заказе (OrderID, ServTypeID,ServDetailID,...) Составные услуги (ServTypeID,...) Одинарные услуги (ServID,ServTypeID,...) Детализация услуги(ServDetailID,...,...,...) Помогите пожалуйста увязать все это в схему с отношениями. Вернее хороша ли описанная мной схема или лучше по другому сделать, например Заказ ( OrderID,CustomerID,ServTypeID,ServDetailID). Сомнения по поводу таблицы "список услуг в заказе", там хранятся составные или одинарные услуги. В общем, труба, надеюсь на помощь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 01:30 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
> Вроде все понимаю, не хватает толчка. Задачу подробнее опишите. Что это за услуги? Есть ли между ними зависимости? Каков характер этих зависимостей? Как формируются пакеты услуг? Как калькулируется стоимость услуги? Как калькулируется стоимость пакета услуг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 17:52 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
guest_20040621, Наверно проще будет, если объясню на конкретном примере: 1) Виза (Услуга по оформлению визы). Атрибуты: кол-во дней, принимающее лицо, причина поездки, тип визы и.т.п. Включает в себя: оплату консульского сбора (рассчитывется на основании атрибутов услуги Виза), оплату за услугу по оформлению визы, медицинскую страховку (у медицинской страховки свои атрибуты: кол-во дней, страхователь, застрахованный 1,..., застрахованный N, возраст, возрастная категория, тип страховки, территория охвата и.т.д Медицинская страховка может также оформляться и отдельно, не в составе услуги "Виза" Сам уже думаю,может не стоит оплаты втыкать в услуги, но общая цена рассчитывается исходя из суммы: конс.сбор+оплата за услугу+мед. страховка. Одновременно с визой клиент может также оформить страховку зеленая карта (свои атрибуты). И стоимость заказа складывается из стоимости всех входящих в заказ услуг ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 18:46 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
> Наверно проще будет, если объясню на конкретном примере: Понятно. Задача абсолютно формальна и регламентирована. Что именно вызывает затруднения? Количество услуг конечно, их атрибуты конечны. Стоимость пакета - это n х (тариф вендора + наценка). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 19:25 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
guest_20040621, непонятно в каких таблицах хранить атрибуты каждой из услуг, и как эти таблицы состыковать в заказе с учетом того, что в заказе может быть несколько услуг ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 20:10 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
> непонятно в каких таблицах хранить атрибуты каждой из услуг Наиболее простой и правильный вариант: описываете услуги классическим образом, в 3НФ. Т. е. для каждой из услуг - своя структура данных. Заказ тоже формируете стандартным образом: каждая услуга может входить в него ноль или один раз, т. е. просто регистрируете связи с услугами в соответствующих таблицах связей. Для предложенного Вами варианта Вы можете сразу забыть про контроль целостности, поскольку будете вынуждены в структуре типа Атрибут -> Значение иметь связанные с кучей внешних таблиц данные (например, страна -> консульство, страна -> валюта консульского сбора, размер консульского сбора). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 22:40 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
guest_20040621, спасибо большое, не совсем понятно, но попробую переварить и набросать схему. Тогда выложу на суд. Если у кого есть мысли по этому поводу, пожалуйста высказывайтесь- каждый ответ способствует пониманию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 22:48 |
|
||
|
БД по услугам
|
|||
|---|---|---|---|
|
#18+
> не совсем понятно Классически - это буквально так, как пишут во всех учебниках. Т. е. берете услугу (например, оформление визы), читаете нормативные документы, читаете анкеты консульств, изучаете перечень документов, которые требуют консульства для оформления визы, изучаете программы консульств по культурному (и не только) обмену (иногда в таких случаях действуют упрощенные правила оформления виз) и в результате получаете структуру данных, отражающую прочитанное. В первом приближении это и будет основа для описания услуги. Предложенный Вами вариант реализации "сущность - атрибут - значение" может использоваться как временный, промежуточный, чтобы понять реально необходимую степень детализации услуги. Т. е. опять же буквально: Пользователи, Услуги, Атрибуты Услуг (Услуги), Заказы (Пользователи), Детализация Заказов (Заказы, Атрибуты услуги, Значения Атрибутов услуги). Такая схема будет плохо работать, хотя формально и будет удовлетворять условию задачи. В ней изначально заложена куча ограничений. Вообще, Ваша задача достаточно объемна для реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2009, 23:20 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=93&tid=1543453]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 355ms |

| 0 / 0 |
