ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование однотипных данных с разными связями на другие таблицы
47 сообщений из 47, показаны все 2 страниц
  все  
Проектирование однотипных данных с разными связями на другие таблицы
    #39262004
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Всем добрый день)

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

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

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

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

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
24.06.2016, 17:01
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263062
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
>лучше и правильнее
Давайте свои критерии лучшести и правильности, например
Объем базы, критичные запросы, требования к времени отклика
Если человек не знает куда он плывет - то для него нет попутного ветра. (С) Сенека
...
Рейтинг: 0 / 0
27.06.2016, 16:40
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263080
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257,

Объём базы очень маленький 1 Гб, критичных запросов нет, требований к времени отклика тоже нет (с таким объёмом всё должно летать).
Меня просто интересует классический подход к решению таких задач. Первый раз с такой столкнулся)
...
Рейтинг: 0 / 0
27.06.2016, 17:16
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263125
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Ну если просто по феншую, то мне первый вариант больше нравится. Добавьте check на таблицы Мероприятий и Показателей чтобы заполненной была только одна ссылка из двух (трех)
...
Рейтинг: 0 / 0
27.06.2016, 18:26
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263134
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Есть еще один вариант - "Наследование в рамках РМД".
Сделать сущности "ВладелецМероприятий", "ВладелецПоказателей" и установить связи 1:0..1
c Вашими "Программами", "Подпрограммами" и т.п.
...
Рейтинг: 0 / 0
27.06.2016, 18:46
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263137
Фотография Egoр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Egoр
Участник
Марков Илья,

Я бы программы и подпрограммы положил в одну иерархическую таблицу, а показатели реализовал как EAV. Мероприятия остались бы простой таблицей.
...
Рейтинг: 0 / 0
27.06.2016, 18:54
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263298
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257Ну если просто по феншую, то мне первый вариант больше нравится. Добавьте check на таблицы Мероприятий и Показателей чтобы заполненной была только одна ссылка из двух (трех)

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

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

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

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

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

Программы и Подпрограммы в одну иерархию запихнуть не могу. Существуют ещё множество таблиц. Я потом на этом собаку съем) К тому же Программы уже предполагается сделать иерархией для хранения шапок Программ и их различных версий.
...
Рейтинг: 0 / 0
28.06.2016, 00:21
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263317
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Марков ИльяКот МатроскинЕсть еще один вариант - "Наследование в рамках РМД".
Сделать сущности "ВладелецМероприятий", "ВладелецПоказателей" и установить связи 1:0..1
c Вашими "Программами", "Подпрограммами" и т.п.

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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Create table EventOwner (IDEventOwner,
                                  ....)

Create table Program (IDEventOwner,
                              ...)
Create table SubProgram ( IDEventOwner,
                                   ...)
Create table Event (IDEvent, 
                           IDEventOwner,
                           ....)
...
Рейтинг: 0 / 0
28.06.2016, 00:59
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263379
Фотография Egoр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Egoр
Участник
Марков ИльяК тому же Программы уже предполагается сделать иерархией для хранения шапок Программ и их различных версий.По мне, так скорее версии нужно в отдельную таблицу складывать, чем объединять их с Программами в одной.
У каждого свои собаки на ужин. :))
Кстати, про версионность Программ в вашей задачке не было ни слова. Может и еще что-нибудь забыли?
...
Рейтинг: 0 / 0
28.06.2016, 08:37
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263407
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Кот Матроскин,

Не совсем понимаю, в чем преимущества данного метода и сущностей владельцев?
...
Рейтинг: 0 / 0
28.06.2016, 09:18
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263413
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Egoр,

У меня версионность Программ с полным их содержимым. Решил хранить все в одних таблицах, так как объем небольшой + часто нужен доступ как к последним версиям, так и к стареньким.
Версионность вообще конечно можно опустить, мне бы без неё увидеть хорошие методы решения моей задачи. Кстати, спасибо за наводку на EAV, тоже не плохой вариант)
...
Рейтинг: 0 / 0
28.06.2016, 09:21
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263430
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Марков Илья,

Как минимум ее гораздо проще расширять - при добавлении еще одной сущности, которая может обладать мероприятиями или показателями, существующие таблицы не меняются никак. У Вас показатели могут быть у трех сущностей - а если бы у 10-ти? В Вашем первом варианте делали бы 10 ссылок?
...
Рейтинг: 0 / 0
28.06.2016, 09:41
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263440
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Кот Матроскин,

Но ведь тогда в данной ситуации будет обратная сторона монеты. Если у Программ и Подпрограмм помимо Мероприятий и Показателей было бы что-то ещё, то тогда было бы ещё больше Владельцев и внешних ключей на них. Но думаю, если такое пойдёт, то уже EAV реально в помощь.
...
Рейтинг: 0 / 0
28.06.2016, 09:48
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263451
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Марков ИльяКот Матроскин,

Но ведь тогда в данной ситуации будет обратная сторона монеты. Если у Программ и Подпрограмм помимо Мероприятий и Показателей было бы что-то ещё, то тогда было бы ещё больше Владельцев и внешних ключей на них.
Не совсем - в данном случае, например, не нужно два ключа, достаточно одного, поскольку
"ВладельцаМероприятий" можно точно так же унаследовать от "ВладельцаПоказателей".
...
Рейтинг: 0 / 0
28.06.2016, 09:58
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263458
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Кот Матроскин,

А, теперь понятно) а это не считается слишком запутанной архитектурой БД?
...
Рейтинг: 0 / 0
28.06.2016, 10:07
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263472
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Марков Илья,

Мной - не считается :) В сравнении с EAV это имхо ясная и стройная архитектура.
Обратите внимание, что в большинстве запросов эти дополнительные таблицы не нужны и, соответственно, их не усложняют - они только обеспечивают ссылочную целостность.
...
Рейтинг: 0 / 0
28.06.2016, 10:22
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263477
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Кот МатроскинМарков Илья,

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

Почему же? Чтобы в одном запросе, например, вытащить Программы и Мероприятия, мне нужно всё равно по доп. таблице пробежаться.
...
Рейтинг: 0 / 0
28.06.2016, 10:27
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263482
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Марков ИльяКот МатроскинМарков Илья,

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

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

Выбрать Программы и Мероприятия этих программ? зачем для этого дополнительная таблица?

Код: sql
1.
2.
3.
4.
...
from Programs p
      left join Events e
      on p.IDEventOwner = e.IDEventOwner
...
Рейтинг: 0 / 0
28.06.2016, 10:34
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263486
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Кот Матроскин,

Блин, и вправду) я почему-то не подумал о соединении сразу по внешним ключам. Спасибо за оригинальную идею!
...
Рейтинг: 0 / 0
28.06.2016, 10:38
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39263488
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Кот Матроскин,

Но если делать наследование владельцев, чтобы вытащить Программы с Показателями нужно всё равно же пробежаться по Владельцам Мероприятий? Или я опять туплю)))
...
Рейтинг: 0 / 0
28.06.2016, 10:39
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264003
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Марков Илья Но если делать наследование владельцев, чтобы вытащить Программы с Показателями нужно всё равно же пробежаться по Владельцам Мероприятий?Да ты должен будешь сделать left join со ВСЕМИ таблицами, но так как у тебя есть сквозная нумерация IDEventOwner (для чего собственно таблица EventOwner и нужна) то в результате будет только то что надо.

Версионность (постановку задачи) тоже тут вываливай. Одна из популярных тем здесь, наряду с наследованием, таблицами с неизвестной структурой (EAV).
...
Рейтинг: 0 / 0
28.06.2016, 16:39
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264008
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Добавлю ключи
Код: sql
1.
2.
3.
4.
5.
6.
7.
Create table EventOwner (IDEventOwner int primary key identity,
Create table Program (IDEventOwner int primary key references EventOwner ,
                              ...)
Create table SubProgram ( IDEventOwner int primary key references EventOwner, prog_id int references Program,
                                   ...)
Create table Event (IDEvent int primary key, 
                           IDEventOwner int references EventOwner,
...
Рейтинг: 0 / 0
28.06.2016, 16:45
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264009
Фотография Egoр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Egoр
Участник
Кот Матроскин,SERG1257 для чего собственно таблица EventOwner и нужна Для чего нужна таблица EventOwner?
...
Рейтинг: 0 / 0
28.06.2016, 16:46
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264051
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Egoр Для чего нужна таблица EventOwner? Для того чтобы на нее наложить ограничение уникальности или первичного ключа
Также туда можно засунуть другие общие поля типа short_name, full_description, date_create, date_last_changed etc.
...
Рейтинг: 0 / 0
28.06.2016, 17:22
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264107
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257Да ты должен будешь сделать left join со ВСЕМИ таблицами

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

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

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

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

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

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

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

Архивы и текущие версии Программ собираюсь хранить в этих же таблицах (данных мало, запросы к архивам будут не редкие). Саму таблицу Программ буду делать в виде иерархии: один уровень - шапка Программы, второй уровень - её версии. Всё остальное в виде обычных таблиц.
...
Рейтинг: 0 / 0
28.06.2016, 18:17
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264206
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Марков Илья,
...
Рейтинг: 0 / 0
28.06.2016, 20:16
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264211
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Марков Илья Не понимаю, общие поля чего?Ну вот смотри и программы и подпрограммы и мероприятия имеют поле - наименование.
Это поле можно хранить либо в таблицах Program, SubProgram и Event или в таблице общем предке EventOwner. В последнем случае можно наложить ограничение на уникальность имени, обеспечить более быстрый поиск по имени и т.д.

Марков Илья запросы к архивам будут не редкиеТебе надо будет решить будут ли версии иметь одно поле с датой d_change или два поля d_from - d_to. Первый вариант более надежен, тебе не нужно обеспечивать d_from = d_to от предыдущей версии, но более затратен для запросов - требуется лишний скан для поиска предыдущей версии.
...
Рейтинг: 0 / 0
28.06.2016, 20:23
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264213
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ViPRos,
...
Рейтинг: 0 / 0
28.06.2016, 20:27
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264214
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ViPRos,
...
Рейтинг: 0 / 0
28.06.2016, 20:27
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264216
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ViPRos,
...
Рейтинг: 0 / 0
28.06.2016, 20:27
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264229
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
хотел сказать, что все это НЕ НАДО программировать
просто надо создать структуру и все
...
Рейтинг: 0 / 0
28.06.2016, 20:44
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264395
Фотография Egoр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Egoр
Участник
Кот Матроскин,
Марков ИльяДля вытаскивания всех владельцев мероприятий (то есть Программ, Подпрограмм и др. таблиц, которые могут появиться в дальнейшем) в одну базовую таблицу, на которую и будут ссылаться все Мероприятия.SERG1257Для того чтобы на нее наложить ограничение уникальности или первичного ключа
Также туда можно засунуть другие общие поля типа short_name, full_description, date_create, date_last_changed etc. То, что предположили форумчане не тянет на объяснение необходимости таблицы EventOwner.
Первое - все владельцы в одной таблице для того, чтобы в одной таблице были все владельцы.
Второе - уникальность обеспечивается только в таблице EventOwner, а в таблицах программ и подпрограмм уже нет. Проще сиквенс использовать, чем целую таблицу.
И никаких общих свойств, кроме идентификатора, у владельцев я не вижу.

Так для чего же нужна таблица EventOwner?

Мне на ум приходят возможность создания внешних ключей и настройки каскадного удаления ивентов при удалении овнера.
Может еще что-то есть?

PS Кстати, почему вы не считаете вашу реализацию EAV. На мой вкус чистой воды оно самое.
Особенно, если вспомнить про показатели мероприятий в свете вашего сообщения про наследование одних от других 19343645 .
...
Рейтинг: 0 / 0
29.06.2016, 08:40
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264444
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
EgoрКот Матроскин,
Марков ИльяДля вытаскивания всех владельцев мероприятий (то есть Программ, Подпрограмм и др. таблиц, которые могут появиться в дальнейшем) в одну базовую таблицу, на которую и будут ссылаться все Мероприятия.SERG1257Для того чтобы на нее наложить ограничение уникальности или первичного ключа
Также туда можно засунуть другие общие поля типа short_name, full_description, date_create, date_last_changed etc. То, что предположили форумчане не тянет на объяснение необходимости таблицы EventOwner.
Первое - все владельцы в одной таблице для того, чтобы в одной таблице были все владельцы.
Второе - уникальность обеспечивается только в таблице EventOwner, а в таблицах программ и подпрограмм уже нет. Проще сиквенс использовать, чем целую таблицу.
И никаких общих свойств, кроме идентификатора, у владельцев я не вижу.

Так для чего же нужна таблица EventOwner?

Предположения форумчан правильные.
Я могу еще раз сформулировать другими словами - таблица нужна, чтобы настроить внешний ключ в "Мероприятиях". Поскольку (как правильно понял Илья Марков) для всех владельцев мероприятий в таблице есть ровно по одной записи (что дополнительно отмечает SERG1257), это возможно сделать.
Смысл таблицы - в обеспечении ссылочной целостности.
EgoрPS Кстати, почему вы не считаете вашу реализацию EAV. На мой вкус чистой воды оно самое.
Особенно, если вспомнить про показатели мероприятий в свете вашего сообщения про наследование одних от других 19343645 .
Ничего общего.
в EAV значения разнородных атрибутов [обычно еще и разнородных] сущностей складываются в единую таблицу вида (IDСущности, НаименованиеАтрибута, ЗначениеАтрибута). Здесь ничего подобного нет.
...
Рейтинг: 0 / 0
29.06.2016, 10:03
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264469
Фотография Egoр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Egoр
Участник
Кот Матроскинв EAV значения разнородных атрибутов [обычно еще и разнородных] сущностей складываются в единую таблицу вида (IDСущности, НаименованиеАтрибута, ЗначениеАтрибута). Здесь ничего подобного нет.Ну конечно! как же я не заметил, в EAV атрибуты, а у ТС атрибутов нет. У него показатели.
Можно тогда поподробнее.
Как будет выглядеть ваша структура 19342916 , когда вы унаследуете в соответствии с 19343645 .
Особенно в части хранения показателей?
...
Рейтинг: 0 / 0
29.06.2016, 10:26
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264507
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
EgoрКот Матроскинв EAV значения разнородных атрибутов [обычно еще и разнородных] сущностей складываются в единую таблицу вида (IDСущности, НаименованиеАтрибута, ЗначениеАтрибута). Здесь ничего подобного нет.Ну конечно! как же я не заметил, в EAV атрибуты, а у ТС атрибутов нет. У него показатели.

Точнее даже сказать так - "...у ТС Показатели", где "Показатели" - сущность предметной области (которая, вообще говоря, может иметь много атрибутов, а не только "значение")
Смысл модели EAV в том, что она экземпляр сущности предметной области "Игрушки"
IDНазваниеЦветДлинаШирина1Машинка игрушечнаяСиний15 см 6 см
Раскладывает на
IDАтрибутЗначение 1"Название""Машинка Игрушечная" 1"Цвет""Синий"1"Длина""15 см";1"Ширина""6 см",
А потом для пользователей системы собирает эти записи вновь в одну сущность

Если прямо в предметной области нет никаких "Игрушек", а есть сразу "Объекты" и "Характеристики"- физическая модель уже не будет EAV, хотя таблицы будут выглядеть очень похоже на первый случай.
Уровень абстракции отличается.
...
Рейтинг: 0 / 0
29.06.2016, 11:14
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264520
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257Тебе надо будет решить будут ли версии иметь одно поле с датой d_change или два поля d_from - d_to. Первый вариант более надежен, тебе не нужно обеспечивать d_from = d_to от предыдущей версии, но более затратен для запросов - требуется лишний скан для поиска предыдущей версии.

Конечно же второй вариант)
...
Рейтинг: 0 / 0
29.06.2016, 11:28
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264551
Фотография Egoр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Egoр
Участник
Кот Матроскин,

То есть, создание таблицы "всех объектов" системы с перепривязыванием атрибутов (сорри, показателей)
от программ, подпрограмм, мероприятий к "объектам" превращает брюки в элегантные шорты.
Если модель выглядит как EAV, плавает как EAV и крякает как EAV, то вероятно это EAV и есть.
Даже если кто-то называет такую модель "Наследование в рамках РМД".

"Значению" не обязательно быть скаляром.
...
Рейтинг: 0 / 0
29.06.2016, 11:48
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264579
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Egoр,

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

По ERM это будет храниться так:
ID ВладелецПоказателейID Наименование ЕдиницаИзмеренияID Значение1 1 Количество разгруженных машин 2 12 1 Количество привезённых игрушек 2 150

По EAV это будет храниться иначе:
ID Атрибут Значение1 ВладелецПоказателейID 11 Наименование Количество разгруженных машин1 ЕдиницаИзмеренияID 21 Значение 12 ВладелецПоказателейID 12 Наименование Количество привезённых игрушек2 ЕдиницаИзмеренияID 22 Значение 150
...
Рейтинг: 0 / 0
29.06.2016, 12:16
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39264873
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Марков Илья Конечно же второй вариант) То бишь ваш запрос на получение текущей версии будет
Код: sql
1.
where prog_id=:prog_id and getdate() between (d_from and d_to)


Несколько моментов
Индексировать d_to более выгодно, так как последнюю (актуальную) запись запрашивают много чаще первой (исторической)
Поэтому d_to для актуальной записи должно быть не null, а датой в будущем (показывать ее можно и как нулл nullif(d_to,'9999'), isnull(@d_to,'9999'))
использовать between более удобно чем d_from<=getdate() and getdate()<=d_to так как вместо короткого getdate() может быть длинное и сложное выражение (подзапрос) которое надо будет обновлять два раза (для двух сравнений)
Для использования between d_to предыдущей записи должно быть чуть раньше чем d_from (на секунду, на три миллисекунды...)
Я знаю, что у ж в вашей-то базе все будет в абсолютном порядке, но вот в моих базах иногда случались неожиданности (дырки, накладки) из-за багов, ручных правок, закачек и т.п.
Поэтому регулярно (по ночам, на выходных, в новый год ...) надо выполнять запрос типа
Код: sql
1.
2.
select * from prog_version p where d_to<>'9999'
 and not exists (select * from prog_version p1 where p.prog_id=p1.prog_id and p.d_to=dateadd('second',1,p1.d_from))


В норме запрос не должен возвращать данных.
...
Рейтинг: 0 / 0
29.06.2016, 17:02
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39265944
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
ViPRosхотел сказать, что все это НЕ НАДО программировать
просто надо создать структуру и все
))) Марков Илья постепенно разработает свою МД, создаст свой инструмент, и тоже будет просто проектировать.
...
Рейтинг: 0 / 0
30.06.2016, 22:25
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39265960
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Марков ИльяВсем добрый день)

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

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

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

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

Модератор: Тема перенесена из форума "Microsoft SQL Server".
Вероятно, Вам нужно изучить сами понятия Программа, Мероприятие, Показатель и посмотреть известные прототипы, такие как
https://programs.gov.ru/Portal/
...
Рейтинг: 0 / 0
30.06.2016, 23:22
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39266189
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257,

Спасибо большое за подсказки, но не понятно, зачем у текущей версии делать between? Можно же d_to сравнить с датой в будущем.

И, кстати, чем лучше для d_to текущей версии делать дату в будущем, чем просто null? Чтобы в условии не писать постоянно isnull? И делать только nullif в выборке для полученных строк, которых само собой будет меньше?
...
Рейтинг: 0 / 0
01.07.2016, 11:32
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39266196
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
Бредятина,

Да, так и есть. Я создаю свою МД со своим блэкджеком и ... :)

По поводу прототипов знаю) Причём эти прототипы могут быть довольно разными)))
...
Рейтинг: 0 / 0
01.07.2016, 11:34
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39266601
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Марков Илья Спасибо большое за подсказки, но не понятно, зачем у текущей версии делать between? Можно же d_to сравнить с датой в будущем.Не понял. Поясни на примере что хотел спросить

Марков Илья И, кстати, чем лучше для d_to текущей версии делать дату в будущем, чем просто null?Если индексировать d_from то разницы нет, но тогда для поиска текущей записи (с максимальной d_from) и условию d_from<=:search_date and :search_date<=d_do придется перебрать все строки. Если версий мало, строки короткие, лежат в одном блоке то разница не замеряема.

автМарков Илья орЧтобы в условии не писать постоянно isnull? isnull/nullif - для пользователя, чтобы не шокировать пользователя датой в будущем.
...
Рейтинг: 0 / 0
01.07.2016, 17:03
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39267132
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257,

Если мне нужна текущая версия, то зачем мне писать:

Код: sql
1.
where prog_id=prog_id and getdate() between (d_from and d_to)



Я ведь могу написать:
Код: sql
1.
where prog_id=prog_id and d_to='9999'
...
Рейтинг: 0 / 0
04.07.2016, 09:56
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39267562
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Чтобы одним (одинаковым) запросом вытаскивать и исторические и текущие записи.
...
Рейтинг: 0 / 0
04.07.2016, 17:26
| Ответить | Цитировать | Написать  
Проектирование однотипных данных с разными связями на другие таблицы
    #39267618
Марков Илья
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Марков Илья
Гость
SERG1257,

Хм, и вправду :) Спасибо!
...
Рейтинг: 0 / 0
04.07.2016, 18:37
| Ответить | Цитировать | Написать  
47 сообщений из 47, показаны все 2 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование однотипных данных с разными связями на другие таблицы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1540312]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 159ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 78ms
get tp. blocked users:
 1ms
others: 11ms
total:  292ms
созд. / загр.: 292ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]