Всем добрый день)

У меня возникла довольно интересная задача, которую я сомневаюсь как реализовать.

В задаче есть Программы, у Программ есть Подпрограммы. То есть Подпрограммы должны быть связаны с Программами как многие к одному.
Так же есть Мероприятия, которые могут быть и у Программ и у Подпрограмм (сами данные в Мероприятиях одинаковые).
И есть Показатели, которые могут быть и Мероприятий, и у Подпрограмм, и у Программ (данные в Показателях также одинаковые).

У меня пока есть три варианта:
1) реализовать все Мероприятия в одной таблице и Показатели в другой таблице. У Мероприятий сделать два внешних ключа на Подпрограммы и Программы. У Показателей 3: на Мероприятия, Подпрограммы, и Программы;
2) реализовать схему Программы <- Подпрограммы <- Мероприятия <- Показатели. В Подпрограммах и Мероприятиях создавать ненужные элементы с наименованием "Отсутствует", чтобы, например, если Мероприятие должно быть у Программы, то его можно было привязать к её Подпрограмме "Отсутствует";
3) реализовать Мероприятия в 3-х таблицах и Показатели в 2-х.

Хотелось бы у вас спросить, как мне лучше и правильнее реализовать данную задачу. Заранее спасибо)

Модератор: Тема перенесена из форума "Microsoft SQL Server".

SERG1257,

Объём базы очень маленький 1 Гб, критичных запросов нет, требований к времени отклика тоже нет (с таким объёмом всё должно летать).
Меня просто интересует классический подход к решению таких задач. Первый раз с такой столкнулся)

SERG1257Ну если просто по феншую, то мне первый вариант больше нравится. Добавьте check на таблицы Мероприятий и Показателей чтобы заполненной была только одна ссылка из двух (трех)

Ну вот мне первый вариант тоже больше нравится.

Кот МатроскинЕсть еще один вариант - "Наследование в рамках РМД".
Сделать сущности "ВладелецМероприятий", "ВладелецПоказателей" и установить связи 1:0..1
c Вашими "Программами", "Подпрограммами" и т.п.

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

Если это так, то чем данная реализация отличается от первого варианта (кроме как вытаскивания внешних ключей в базовые таблицы)?

EgoрЯ бы программы и подпрограммы положил в одну иерархическую таблицу, а показатели реализовал как EAV. Мероприятия остались бы простой таблицей.

Программы и Подпрограммы в одну иерархию запихнуть не могу. Существуют ещё множество таблиц. Я потом на этом собаку съем) К тому же Программы уже предполагается сделать иерархией для хранения шапок Программ и их различных версий.

Кот Матроскин,

Не совсем понимаю, в чем преимущества данного метода и сущностей владельцев?

Egoр,

У меня версионность Программ с полным их содержимым. Решил хранить все в одних таблицах, так как объем небольшой + часто нужен доступ как к последним версиям, так и к стареньким.
Версионность вообще конечно можно опустить, мне бы без неё увидеть хорошие методы решения моей задачи. Кстати, спасибо за наводку на EAV, тоже не плохой вариант)

Кот Матроскин,

Но ведь тогда в данной ситуации будет обратная сторона монеты. Если у Программ и Подпрограмм помимо Мероприятий и Показателей было бы что-то ещё, то тогда было бы ещё больше Владельцев и внешних ключей на них. Но думаю, если такое пойдёт, то уже EAV реально в помощь.

Кот Матроскин,

А, теперь понятно) а это не считается слишком запутанной архитектурой БД?

Кот МатроскинМарков Илья,

Обратите внимание, что в большинстве запросов эти дополнительные таблицы не нужны

Почему же? Чтобы в одном запросе, например, вытащить Программы и Мероприятия, мне нужно всё равно по доп. таблице пробежаться.

Кот Матроскин,

Блин, и вправду) я почему-то не подумал о соединении сразу по внешним ключам. Спасибо за оригинальную идею!

Кот Матроскин,

Но если делать наследование владельцев, чтобы вытащить Программы с Показателями нужно всё равно же пробежаться по Владельцам Мероприятий? Или я опять туплю)))

SERG1257Да ты должен будешь сделать left join со ВСЕМИ таблицами

Ну разве что по Владельцам показателей не надо)

EgoрДля чего нужна таблица EventOwner?

Для вытаскивания всех владельцев мероприятий (то есть Программ, Подпрограмм и др. таблиц, которые могут появиться в дальнейшем) в одну базовую таблицу, на которую и будут ссылаться все Мероприятия.

SERG1257Также туда можно засунуть другие общие поля типа short_name, full_description, date_create, date_last_changed etc.

Не понимаю, общие поля чего?

SERG1257Версионность (постановку задачи) тоже тут вываливай. Одна из популярных тем здесь, наряду с наследованием, таблицами с неизвестной структурой (EAV).

Задача состоит в реализации полного архивирования Программы (со всеми внутренностями) и копирования её для внесения дальнейших изменений по запросу пользователя.

Архивы и текущие версии Программ собираюсь хранить в этих же таблицах (данных мало, запросы к архивам будут не редкие). Саму таблицу Программ буду делать в виде иерархии: один уровень - шапка Программы, второй уровень - её версии. Всё остальное в виде обычных таблиц.