|
|
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Марков Илья, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2016, 20:16 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Марков Илья Не понимаю, общие поля чего?Ну вот смотри и программы и подпрограммы и мероприятия имеют поле - наименование. Это поле можно хранить либо в таблицах Program, SubProgram и Event или в таблице общем предке EventOwner. В последнем случае можно наложить ограничение на уникальность имени, обеспечить более быстрый поиск по имени и т.д. Марков Илья запросы к архивам будут не редкиеТебе надо будет решить будут ли версии иметь одно поле с датой d_change или два поля d_from - d_to. Первый вариант более надежен, тебе не нужно обеспечивать d_from = d_to от предыдущей версии, но более затратен для запросов - требуется лишний скан для поиска предыдущей версии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2016, 20:23 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
ViPRos, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2016, 20:27 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
ViPRos, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2016, 20:27 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
ViPRos, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2016, 20:27 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
хотел сказать, что все это НЕ НАДО программировать просто надо создать структуру и все ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2016, 20:44 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, Марков ИльяДля вытаскивания всех владельцев мероприятий (то есть Программ, Подпрограмм и др. таблиц, которые могут появиться в дальнейшем) в одну базовую таблицу, на которую и будут ссылаться все Мероприятия.SERG1257Для того чтобы на нее наложить ограничение уникальности или первичного ключа Также туда можно засунуть другие общие поля типа short_name, full_description, date_create, date_last_changed etc. То, что предположили форумчане не тянет на объяснение необходимости таблицы EventOwner. Первое - все владельцы в одной таблице для того, чтобы в одной таблице были все владельцы. Второе - уникальность обеспечивается только в таблице EventOwner, а в таблицах программ и подпрограмм уже нет. Проще сиквенс использовать, чем целую таблицу. И никаких общих свойств, кроме идентификатора, у владельцев я не вижу. Так для чего же нужна таблица EventOwner? Мне на ум приходят возможность создания внешних ключей и настройки каскадного удаления ивентов при удалении овнера. Может еще что-то есть? PS Кстати, почему вы не считаете вашу реализацию EAV. На мой вкус чистой воды оно самое. Особенно, если вспомнить про показатели мероприятий в свете вашего сообщения про наследование одних от других 19343645 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 08:40 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
EgoрКот Матроскин, Марков ИльяДля вытаскивания всех владельцев мероприятий (то есть Программ, Подпрограмм и др. таблиц, которые могут появиться в дальнейшем) в одну базовую таблицу, на которую и будут ссылаться все Мероприятия.SERG1257Для того чтобы на нее наложить ограничение уникальности или первичного ключа Также туда можно засунуть другие общие поля типа short_name, full_description, date_create, date_last_changed etc. То, что предположили форумчане не тянет на объяснение необходимости таблицы EventOwner. Первое - все владельцы в одной таблице для того, чтобы в одной таблице были все владельцы. Второе - уникальность обеспечивается только в таблице EventOwner, а в таблицах программ и подпрограмм уже нет. Проще сиквенс использовать, чем целую таблицу. И никаких общих свойств, кроме идентификатора, у владельцев я не вижу. Так для чего же нужна таблица EventOwner? Предположения форумчан правильные. Я могу еще раз сформулировать другими словами - таблица нужна, чтобы настроить внешний ключ в "Мероприятиях". Поскольку (как правильно понял Илья Марков) для всех владельцев мероприятий в таблице есть ровно по одной записи (что дополнительно отмечает SERG1257), это возможно сделать. Смысл таблицы - в обеспечении ссылочной целостности. EgoрPS Кстати, почему вы не считаете вашу реализацию EAV. На мой вкус чистой воды оно самое. Особенно, если вспомнить про показатели мероприятий в свете вашего сообщения про наследование одних от других 19343645 . Ничего общего. в EAV значения разнородных атрибутов [обычно еще и разнородных] сущностей складываются в единую таблицу вида (IDСущности, НаименованиеАтрибута, ЗначениеАтрибута). Здесь ничего подобного нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 10:03 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинв EAV значения разнородных атрибутов [обычно еще и разнородных] сущностей складываются в единую таблицу вида (IDСущности, НаименованиеАтрибута, ЗначениеАтрибута). Здесь ничего подобного нет.Ну конечно! как же я не заметил, в EAV атрибуты, а у ТС атрибутов нет. У него показатели. Можно тогда поподробнее. Как будет выглядеть ваша структура 19342916 , когда вы унаследуете в соответствии с 19343645 . Особенно в части хранения показателей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 10:26 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
EgoрКот Матроскинв EAV значения разнородных атрибутов [обычно еще и разнородных] сущностей складываются в единую таблицу вида (IDСущности, НаименованиеАтрибута, ЗначениеАтрибута). Здесь ничего подобного нет.Ну конечно! как же я не заметил, в EAV атрибуты, а у ТС атрибутов нет. У него показатели. Точнее даже сказать так - "...у ТС Показатели", где "Показатели" - сущность предметной области (которая, вообще говоря, может иметь много атрибутов, а не только "значение") Смысл модели EAV в том, что она экземпляр сущности предметной области "Игрушки" IDНазваниеЦветДлинаШирина1Машинка игрушечнаяСиний15 см 6 см Раскладывает на IDАтрибутЗначение 1"Название""Машинка Игрушечная" 1"Цвет""Синий"1"Длина""15 см";1"Ширина""6 см", А потом для пользователей системы собирает эти записи вновь в одну сущность Если прямо в предметной области нет никаких "Игрушек", а есть сразу "Объекты" и "Характеристики"- физическая модель уже не будет EAV, хотя таблицы будут выглядеть очень похоже на первый случай. Уровень абстракции отличается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 11:14 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
SERG1257Тебе надо будет решить будут ли версии иметь одно поле с датой d_change или два поля d_from - d_to. Первый вариант более надежен, тебе не нужно обеспечивать d_from = d_to от предыдущей версии, но более затратен для запросов - требуется лишний скан для поиска предыдущей версии. Конечно же второй вариант) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 11:28 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, То есть, создание таблицы "всех объектов" системы с перепривязыванием атрибутов (сорри, показателей) от программ, подпрограмм, мероприятий к "объектам" превращает брюки в элегантные шорты. Если модель выглядит как EAV, плавает как EAV и крякает как EAV, то вероятно это EAV и есть. Даже если кто-то называет такую модель "Наследование в рамках РМД". "Значению" не обязательно быть скаляром. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 11:48 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 12:16 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Марков Илья Конечно же второй вариант) То бишь ваш запрос на получение текущей версии будет Код: sql 1. Несколько моментов Индексировать 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. В норме запрос не должен возвращать данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 17:02 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
ViPRosхотел сказать, что все это НЕ НАДО программировать просто надо создать структуру и все ))) Марков Илья постепенно разработает свою МД, создаст свой инструмент, и тоже будет просто проектировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2016, 22:25 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Марков ИльяВсем добрый день) У меня возникла довольно интересная задача, которую я сомневаюсь как реализовать. В задаче есть Программы, у Программ есть Подпрограммы. То есть Подпрограммы должны быть связаны с Программами как многие к одному. Так же есть Мероприятия, которые могут быть и у Программ и у Подпрограмм (сами данные в Мероприятиях одинаковые). И есть Показатели, которые могут быть и Мероприятий, и у Подпрограмм, и у Программ (данные в Показателях также одинаковые). У меня пока есть три варианта: 1) реализовать все Мероприятия в одной таблице и Показатели в другой таблице. У Мероприятий сделать два внешних ключа на Подпрограммы и Программы. У Показателей 3: на Мероприятия, Подпрограммы, и Программы; 2) реализовать схему Программы <- Подпрограммы <- Мероприятия <- Показатели. В Подпрограммах и Мероприятиях создавать ненужные элементы с наименованием "Отсутствует", чтобы, например, если Мероприятие должно быть у Программы, то его можно было привязать к её Подпрограмме "Отсутствует"; 3) реализовать Мероприятия в 3-х таблицах и Показатели в 2-х. Хотелось бы у вас спросить, как мне лучше и правильнее реализовать данную задачу. Заранее спасибо) Модератор: Тема перенесена из форума "Microsoft SQL Server". Вероятно, Вам нужно изучить сами понятия Программа, Мероприятие, Показатель и посмотреть известные прототипы, такие как https://programs.gov.ru/Portal/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2016, 23:22 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
SERG1257, Спасибо большое за подсказки, но не понятно, зачем у текущей версии делать between? Можно же d_to сравнить с датой в будущем. И, кстати, чем лучше для d_to текущей версии делать дату в будущем, чем просто null? Чтобы в условии не писать постоянно isnull? И делать только nullif в выборке для полученных строк, которых само собой будет меньше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2016, 11:32 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Бредятина, Да, так и есть. Я создаю свою МД со своим блэкджеком и ... :) По поводу прототипов знаю) Причём эти прототипы могут быть довольно разными))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2016, 11:34 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Марков Илья Спасибо большое за подсказки, но не понятно, зачем у текущей версии делать between? Можно же d_to сравнить с датой в будущем.Не понял. Поясни на примере что хотел спросить Марков Илья И, кстати, чем лучше для d_to текущей версии делать дату в будущем, чем просто null?Если индексировать d_from то разницы нет, но тогда для поиска текущей записи (с максимальной d_from) и условию d_from<=:search_date and :search_date<=d_do придется перебрать все строки. Если версий мало, строки короткие, лежат в одном блоке то разница не замеряема. автМарков Илья орЧтобы в условии не писать постоянно isnull? isnull/nullif - для пользователя, чтобы не шокировать пользователя датой в будущем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2016, 17:03 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
SERG1257, Если мне нужна текущая версия, то зачем мне писать: Код: sql 1. Я ведь могу написать: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2016, 09:56 |
|
||
|
Проектирование однотипных данных с разными связями на другие таблицы
|
|||
|---|---|---|---|
|
#18+
Чтобы одним (одинаковым) запросом вытаскивать и исторические и текущие записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2016, 17:26 |
|
||
|
|

start [/forum/search_topic.php?author=Pixel&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 442ms |
| total: | 710ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...