ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Идентифицирующие отношения, как правильно сделать миграцию ключей?
14 сообщений из 14, страница 1 из 1
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864918
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
Есть несколько таблиц, связанных друг с другом, по сути дочерние не могут существовать независимо от родительских, и при этом из самой нижней дочерней нужно легко получить поле любой родительской. Самое красивое решение напрашивается - связать идентифицирующими отношениями.
Когда стал рисовать, то задался вопросом: а если в самой нижней таблице есть часть ключа от самой верхней, то почему бы не связать ее сразу же с верхней, а не по цепочке? Ведь нет никакой разницы, из какой таблицы берется, допустим, contract_id, они во всех таблицах одинаковы, т.к. мигрируют между всеми.
Для иллюстрации привожу две картинки, скажите, какая из них правильная?
...
Рейтинг: 0 / 0
28.01.2015, 00:19
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864921
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
...
Рейтинг: 0 / 0
28.01.2015, 00:20
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864924
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
Просто прописывать в SQL внешний ключ по одному полю вроде легче, чем один ключ сразу по нескольким полям.
...
Рейтинг: 0 / 0
28.01.2015, 00:23
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864928
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
И я могу в обоих случаях написать запрос:
Код: sql
1.
2.
3.
SELECT wagon_type, contract_number
FROM wagon w
INNER JOIN contract c ON c.id = w.contract_id



А могу так:
Код: sql
1.
2.
3.
4.
5.
SELECT wagon_type, contract_number
FROM wagon w
INNER JOIN plan p ON (p.id = w.plan_id) AND (p.contract_id = w.contract_id) AND (p.cargo_id = w.cargo_id)
INNER JOIN contract_cargo cc ON (cc.contract_id = p.contract_id) AND (cc.cargo_id = p.cargo_id)
INNER JOIN contract c ON c.id = cc.contract_id



И как правильно?
...
Рейтинг: 0 / 0
28.01.2015, 00:30
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864938
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
И два варианта создания таблицы для обеих схем. Какая из них правильная?
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE `wagon` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `plan_id` int(11) unsigned DEFAULT NULL,
  `contract_id` int(11) unsigned DEFAULT NULL,
  `cargo_id` int(11) unsigned DEFAULT NULL,
  `wagon_type` char(1) DEFAULT NULL,
  PRIMARY KEY (`id`,`plan_id`,`contract_id`,`cargo_id`),
  CONSTRAINT `wagon_fk1` FOREIGN KEY (`plan_id`, `contract_id`, `cargo_id`) REFERENCES `plan` (`id`, `contract_id`, `cargo_id`)
)



Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE `wagon` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `plan_id` int(11) unsigned DEFAULT NULL,
  `contract_id` int(11) unsigned DEFAULT NULL,
  `cargo_id` int(11) unsigned DEFAULT NULL,
  `wagon_type` char(1) DEFAULT NULL,
  PRIMARY KEY (`id`,`plan_id`,`contract_id`,`cargo_id`),
  CONSTRAINT `wagon_fk1` FOREIGN KEY (`plan_id`) REFERENCES `plan` (`id`),
  CONSTRAINT `wagon_fk2` FOREIGN KEY (`contract_id`) REFERENCES `contract` (`id`),
  CONSTRAINT `wagon_fk3` FOREIGN KEY (`cargo_id`) REFERENCES `cargo` (`id`)
)
...
Рейтинг: 0 / 0
28.01.2015, 00:55
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864939
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
Только в ключах NOT NULL конечно.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE `wagon` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `plan_id` int(11) unsigned NOT NULL,
  `contract_id` int(11) unsigned NOT NULL,
  `cargo_id` int(11) unsigned NOT NULL,
  `wagon_type` char(1) DEFAULT NULL,
  PRIMARY KEY (`id`,`plan_id`,`contract_id`,`cargo_id`),
  CONSTRAINT `wagon_fk1` FOREIGN KEY (`plan_id`, `contract_id`, `cargo_id`) REFERENCES `plan` (`id`, `contract_id`, `cargo_id`)
)



Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE `wagon` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `plan_id` int(11) unsigned NOT NULL,
  `contract_id` int(11) unsigned NOT NULL,
  `cargo_id` int(11) unsigned NOT NULL,
  `wagon_type` char(1) DEFAULT NULL,
  PRIMARY KEY (`id`,`plan_id`,`contract_id`,`cargo_id`),
  CONSTRAINT `wagon_fk1` FOREIGN KEY (`plan_id`) REFERENCES `plan` (`id`),
  CONSTRAINT `wagon_fk2` FOREIGN KEY (`contract_id`) REFERENCES `contract` (`id`),
  CONSTRAINT `wagon_fk3` FOREIGN KEY (`cargo_id`) REFERENCES `cargo` (`id`)
)
...
Рейтинг: 0 / 0
28.01.2015, 00:57
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38864982
R7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
R7
Гость
svnvlad,

В некоторых специфичных случаях денормализация по связям имеет место быть. Например, для хранения просчитанных деревьев, которые живут только на чтение.
Для тех квадратиков, что вы нарисовали смысла отходить от феншуя нет.
Какие цели преследуются? Для того, чтобы каждый раз не писать многоэтажные джойны есть вьюхи.
...
Рейтинг: 0 / 0
28.01.2015, 03:50
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38865020
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
R7svnvlad,

В некоторых специфичных случаях денормализация по связям имеет место быть. Например, для хранения просчитанных деревьев, которые живут только на чтение.
Для тех квадратиков, что вы нарисовали смысла отходить от феншуя нет.
Какие цели преследуются? Для того, чтобы каждый раз не писать многоэтажные джойны есть вьюхи.
А что под феншуем имеете в виду? Разве миграция ключей не входит в феншуй?
Предполагалось, что одна сущность (вагон) будет иметь связи с другими сущностями, которые ее обрабатывают (КПП, склад и т.д.) в соотношении 1:1. Т.е. к таблице вагон пристыковывается таблица отдела, через который вагон один раз проходит, затем другой отдел и т.д. Чем делать двухуровневое соединение, логично предположить, что это ближе к категориям, т.е. первичный ключ один и тот же.
...
Рейтинг: 0 / 0
28.01.2015, 08:13
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38865022
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
R7Для тех квадратиков, что вы нарисовали смысла отходить от феншуя нет.

Соотношение многие-ко-многим не является случаем, когда первичный ключ должен мигрировать? Ведь без одного из id дочерняя сущность не может существовать. Или решение сделать все связи НЕидентифицирующими определяется просто удобством (стандартностью) дальнейшего составления запросов?
...
Рейтинг: 0 / 0
28.01.2015, 08:16
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38865055
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
svnvladR7Для тех квадратиков, что вы нарисовали смысла отходить от феншуя нет.

Соотношение многие-ко-многим не является случаем, когда первичный ключ должен мигрировать?
Нет, необязательно.
Он должен мигрировать, если Вы по классике делаете в связующей таблице первичный ключ из ключей связываемых сущностей. Если Вы вводите суррогат, включать дополнительно в ключ еще и ключи родительских объектов - ну можно, конечно, но необязательно.
...
Рейтинг: 0 / 0
28.01.2015, 09:16
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38865132
R7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
R7
Гость
svnvladА что под феншуем имеете в виду?

Вы спрашиваете, стоит ли нарушить 4НФ, чтобы стало что-то там хорошо.
Да. На практике это почти всегда так. Только, за это придется доплатить. На вашем простом примере доплатить придется лишними контролями целостности.
svnvladРазве миграция ключей не входит в феншуй?

У вас слишком вольные представления о миграции ключей. Это же не физическая возможность лепить ФК куда станет удобно.
...
Рейтинг: 0 / 0
28.01.2015, 10:14
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38865133
R7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
R7
Гость
R7нарушить 4НФ
третью с половиной
...
Рейтинг: 0 / 0
28.01.2015, 10:16
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38865241
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
svnvladКогда стал рисовать, то задался вопросом: а если в самой нижней таблице есть часть ключа от самой верхней, то почему бы не связать ее сразу же с верхней, а не по цепочке? Ведь нет никакой разницы, из какой таблицы берется, допустим, contract_id, они во всех таблицах одинаковы, т.к. мигрируют между всеми.
Это не так.

Если "связать сразу с верхней", то в первую очередь получится следующее: wagon связан с contract по contract_id, wagon связан с plan по plan_id, как следствие, contract_id в wagon может не совпадать с contract_id в plan.

Если "связать сразу с верхней", и при этом contract_id также является полем первичного ключа в plan, то в результате в wagon окажется два атрибута для contract_id: один мигрировавший из contract, другой - из plan.

Даже если средство моделирования позволит их объединить, то есть задать использование одного атрибута в двух внешних ключах, это не даст ничего по сравнению с первым вариантом - просто лишний внешний ключ, на проверку которого будут тратиться дополнительные ресурсы, но который не несёт никакой дополнительной надёжности.
...
Рейтинг: 0 / 0
28.01.2015, 11:20
| Ответить | Цитировать | Написать  
Идентифицирующие отношения, как правильно сделать миграцию ключей?
    #38866128
svnvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svnvlad
Участник
softwarersvnvladКогда стал рисовать, то задался вопросом: а если в самой нижней таблице есть часть ключа от самой верхней, то почему бы не связать ее сразу же с верхней, а не по цепочке? Ведь нет никакой разницы, из какой таблицы берется, допустим, contract_id, они во всех таблицах одинаковы, т.к. мигрируют между всеми.
Это не так.

Если "связать сразу с верхней", то в первую очередь получится следующее: wagon связан с contract по contract_id, wagon связан с plan по plan_id, как следствие, contract_id в wagon может не совпадать с contract_id в plan.

Спасибо. Я это уже понял.
...
Рейтинг: 0 / 0
29.01.2015, 02:51
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Идентифицирующие отношения, как правильно сделать миграцию ключей?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=23&tid=1540662]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 45ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 56ms
get tp. blocked users:
 2ms
others: 11ms
total:  158ms
созд. / загр.: 158ms
x
x
Закрыть


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