powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование однотипных данных с разными связями на другие таблицы
22 сообщений из 47, страница 2 из 2
Проектирование однотипных данных с разными связями на другие таблицы
    #39264206
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Марков Илья,
...
Рейтинг: 0 / 0
Проектирование однотипных данных с разными связями на другие таблицы
    #39264211
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Марков Илья Не понимаю, общие поля чего?Ну вот смотри и программы и подпрограммы и мероприятия имеют поле - наименование.
Это поле можно хранить либо в таблицах Program, SubProgram и Event или в таблице общем предке EventOwner. В последнем случае можно наложить ограничение на уникальность имени, обеспечить более быстрый поиск по имени и т.д.

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

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

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

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

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

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

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

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

"Значению" не обязательно быть скаляром.
...
Рейтинг: 0 / 0
Проектирование однотипных данных с разными связями на другие таблицы
    #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
Проектирование однотипных данных с разными связями на другие таблицы
    #39264873
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
Проектирование однотипных данных с разными связями на другие таблицы
    #39265944
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosхотел сказать, что все это НЕ НАДО программировать
просто надо создать структуру и все
))) Марков Илья постепенно разработает свою МД, создаст свой инструмент, и тоже будет просто проектировать.
...
Рейтинг: 0 / 0
Проектирование однотипных данных с разными связями на другие таблицы
    #39265960
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Марков ИльяВсем добрый день)

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

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

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

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

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

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

И, кстати, чем лучше для d_to текущей версии делать дату в будущем, чем просто null? Чтобы в условии не писать постоянно isnull? И делать только nullif в выборке для полученных строк, которых само собой будет меньше?
...
Рейтинг: 0 / 0
Проектирование однотипных данных с разными связями на другие таблицы
    #39266196
Бредятина,

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

По поводу прототипов знаю) Причём эти прототипы могут быть довольно разными)))
...
Рейтинг: 0 / 0
Проектирование однотипных данных с разными связями на другие таблицы
    #39266601
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
Проектирование однотипных данных с разными связями на другие таблицы
    #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
Проектирование однотипных данных с разными связями на другие таблицы
    #39267562
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чтобы одним (одинаковым) запросом вытаскивать и исторические и текущие записи.
...
Рейтинг: 0 / 0
Проектирование однотипных данных с разными связями на другие таблицы
    #39267618
SERG1257,

Хм, и вправду :) Спасибо!
...
Рейтинг: 0 / 0
22 сообщений из 47, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование однотипных данных с разными связями на другие таблицы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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