Доброго времени суток!
В проектируемой ИС есть несколько типов услуг. Все эти услуги занесены в одну общую таблицу, но зато есть различные параметры у каждого типа услуг, которые описываются в отдельных таблицах (для каждого типа услуг своя таблица с параметрами).
Для того чтобы пользовательскому коду было легче разобраться с услугой какого типа он имеет сейчас дело и какие параметры он может вызывать, хотелось бы воплотить следующее: создать таблицу типов услуг, и в общей таблице услуг добавить поле-внешний ключ от созданной таблицы. На основании определенного типа он будет обращаться к нужной таблице параметров. Насколько это решение считается корректным?
Просто не давно в сети встретил статью, где в пух и прах разносят данный подход, причем не сильно это все аргументируя. Хотелось бы уточнить у бывалых. Заранее спасибо.

автора как там предлагалось сделать?
Там предлагалось:
Делаются отдельные таблицы под каждый тип (там рассматривался на примере тип транспортных средств). О наследовании таблиц там ни слова. Таблица с описанием всех типов (ту, о которой я говорил в начале поста, чтобы пользовательский код мог автоматически определять тип объекта с которым имеет дело) категорически возбранялась - в статье утверждалось, что это метаданные, и их нужно полностью закодировать в логике сервера приложений, тем самым уменьшатся запросы к БД, а в случае изменения логики, править придется только код апплекейшн сервера.

авторСсылкой не поделитесь? :)
В том то и дело, что наткнулся на эту статью совершенно случайно, не сохранил.

Т.е. основная мысль статьи той, метаданные хранить на уровне логике паттернов. Хотя на мой взгляд мы как раз гибкость тут и теряем. Поэтому и хотел уточнить,



авторнаследование таблиц называется
Совершенно верно на уровне БД - будет организовано наследование таблиц.

авторКак это будет выглядеть?
Если про мой вариант реализации на уровне клиентского кода, то примерно будет следующее:
Общий Класс Service реализующий Интерфейс ServiceInt к примеру. От это класса наследуются классы описывающие каждый тип услуг
В процессе работы приложения мы получаем объект типа Service и чтобы полноценно работать с этим объектом мы определяем подробно его тип через метод GetСoncreteTypeService().
Этот метод делает запрос в БД, цепляет идентификатор типа услуг от туда и уже на основании этого метод возвращает либо тип услуг, либо возвращает приведенный объект конкретного типа услуг. А конкретный класс типа услуг работает с заранее определённой для него таблицей.



авторЭти услуги отличаются только набором атрибутов (EAV ?).
Нет не только - в зависимости от типов услуг по разному рассчитывается тариффикационная сетка. не думаю, что EAV будет оптимальным применением.

LSV, я пока не на чем не настаиваю. Сейчас все в стадии проектирования, в стадии обсуждения и я премного благодарен форумчанам, Вам в частности, за участие.

Опишу немного ситуацию по подробней. В той ИС, которая сейчас проектируется, существует всего два типа услуг.
1) Количественная. Тут все очень просто Петров положил 5 кирпичей получил 5 рублей (по рублю на кирпич). Количество оказываемых услуг умножается на тарифную ставку.
2) Временная, тут немного посложней. Во-первых, Петров проработал 3 часа 21 минута - значит тарифная часовая ставка должна быть умножена на временной результат. Во-вторых, каждая временная услуга содержит дополнительные параметр такие как минимальное время работы, часы подготовке к работе. Т.е. если минималка содержит 5 часов, а Петров отработал 3 часа, то его тарифная ставка умножится на 5. К любому результату произведения так же прибавятся тарифная ставка умноженная на количество часов подготовки к работе.

И ещё тариф - это произвольная комбинация услуг различного типа.

Других типов услуг не предвидятся пока. Но не факт, что их не будет. Но пока даже фантазии не хватает какие типы услуг могут быть ещё...

koJIo6ok, про кирпичи я утрировал. "кирпич" можно заменить на любую другую услугу строительную и нестроительную, которую могут выполнять целые бригады к примеру...

Такого ТЗ ИС.