Частично воспользовался Вашей идеей. Теперь появился вопрос, добавились еще две услуги, со своими параметрами, все бы ничего, смущает только то, что для каждого отдельного вида услуги - есть одна таблица исполнителей. Теперь, когда нужно делать выборку по исполнителям, приходится соединять все эти таблицы перед этим. Как вы считаете, насколько это неудачно, если можно так выразиться?
Похоже, это действительно поможет! "Создать два связанных поля: Employe_translation_id, Employe_notarial_id" - это просто два поля в таблице в новой таблице ServiceInfo? Связаны логически? Т.е. если и там и там установлено значение, то мы знаем что текст заверен, так? Спасибо.
Спасибо!
Получается имеем по одной дополнительной таблице, для каждого вида услуги (с разными доп. полями) привязанными к заказу внешним ключом?
Скажите, если одна из услуг использует все данные другой услуги, добавляя при этом некоторые свои, можно ли связать таблицу с этой услугой не с заказом, а с оказанной услугой (1го типа), и программно, когда понадобиться вывод, то использовать те общие поля? Не влечет это подводных камней в простом случае?
Этот вопрос имеет скорее общий характер - "когда объект должен иметь признаки нескольких предков", а конкретика в этом вопросе, которую вы путаете с "разными видами соусов", приведена для лучшего понимания, моего и остальных, ведь всегда просят конкретные примеры.
И да, множественное наследование в c# не поддерживается.
Нет, вопрос не в этом. Пусть класс-родитель абстрактный, от него унаследовано много наследников - реальных классов. В один момент в интерфейс абстрактного класса добавляют новый метод. Пусть почти все наследники реализовывают его у себя, а для некоторых наследников - этот метод не имеет смысла вообще. Проще говоря вся система абстракций ломается. Можно закрыть на это глаза и например никогда не вызывать этот метод у наследников не реализующих его, а если вызывать - то например возбуждать исключение, или ничего не делать, или еще что. Я так понимаю, что лучшее решение в плане - "чтобы все было как надо" - реализовывать новую систему абстракций, где такой ситуации не возникнет, но на практике наверняка так делать не всегда получится, поэтому такой вопрос возник, как обычно поступают.
sim3x: а я начитался, что к вопросу хранения данных надо подходить в самый последний момент, мол релиционная база, объектная или файл обычный - потом выберешь. На практике особо не переживают по этому поводу?
Vapaamies: Была такая архитектура: Заказ хранит свои подзаказы в себе. Теперь добавилось новая возможность, указывать сверхурочную работу по одному из тасков, на котором строится заказ. Для программы нужно, чтобы эту сверхурочность можно было бы обработать так же как и заказ со своим подзаказом. Но сверхурочность не может быть совсем отдельным заказом, потому что связанна на прямую с заказом (указывается, что это сверхурочная работа для конкретного заказа, при удалении, изменении его она тоже удаляется, изменяться.). Получается что заказ теперь должен хранить в себе и заказ на сверх урочность отдельно? Или откуда заказ будет вообще знать что с ним связана сверхурочная работа?
sim3x: нет, дело в том, что архитектура программы построена на "списке транзакций". Есть рабочая модель данных, которая ничего не знает о БД. Заказы умеют добавлять подзаказы, и.т.д., а на каждую операцию есть отдельный класс, который работает с реляционной БД. Поэтому при составлении связей классов я не думаю про базу, как они хранятся и т. д. Нужна гибкая модель, которая позволит добавлять сверхурочную работу по заказу.
Наверно я не точно объяснил. Есть два вида заказов - заказ который делает заказчик (CustomerOrder), и заказ, который дают сотруднику (EmployeeOrder) - я назвал последние - подзаказами. На основе заказа от заказчика - сотрудникам выделяют подзаказы, и они их выполняют. Возможные ситуации: 1) У заказа есть один подзаказ который совпадает с заказом (Заказчик попросил 10 апельсинов, а мы попросили у Васи-сотрудника 10 апельсинов). 2) Заказ дробят (6 апельсинов Вася и 4 Сережа). 3) Заказу соответствует 1 но другой подзаказ.
Заказы и подзаказы - по сути отдельные сущности, потому что зачастую обрабатываются независимо - заказам не интересно из каких подзаказов они состоят, а подзаказам - в какой заказ входят.
Но в одном "модуле" программы, в так сказать инициализирующем - заказам ставятся в соответсвие подзаказы. Надо уметь их добавлять, удалять, обновлять. Если заказ удалить то надо стереть и его подзаказы.
Теперь про сверхурочность. Это требование добавили для одного вида Taska. Т.е. есть заказ основанный на этом типе Taska. (заказ на 10 апельсинов). У Этого заказа есть подзаказ - с совпадающим Task'ом - Вася - 10 апельсинов. Далее в программе добавляют к этому заказу сверхурочную работу (еще 2 апельсина сверхурочно), эти два апельсина должны быть обработаны отдельно от тех 10, потому что имеют свою цену, свое описание, и т д, они имеют и свой подзаказ - (тот же сотрудник сверхурочно 2 апельсина). Но удаляя заказ мы должны удалить и сверхурочный заказ на него.
sim3x: "тип_таска = М2М(ТипТаска) // сверурочное обучение". Это не опечатка? Получается что тут создается смешанный тип таска "сверхурочность"+"обучение"? я, к сожалению, не понимаю тут использование терминов M2M и FK, они к БД имеют отношение? или говорят о связи классов в данном случае?
получается в Вашем примере каждый "Таск" знает какому ЗапросуЗаказчика он пренадлежит, а надо, чтобы каждый ЗапросЗаказчика знал из каких Тасков он состоит