Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Идентифицирующие отношения, как правильно сделать миграцию ключей? / 14 сообщений из 14, страница 1 из 1
28.01.2015, 00:19
    #38864918
svnvlad
svnvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Идентифицирующие отношения, как правильно сделать миграцию ключей?
Есть несколько таблиц, связанных друг с другом, по сути дочерние не могут существовать независимо от родительских, и при этом из самой нижней дочерней нужно легко получить поле любой родительской. Самое красивое решение напрашивается - связать идентифицирующими отношениями.
Когда стал рисовать, то задался вопросом: а если в самой нижней таблице есть часть ключа от самой верхней, то почему бы не связать ее сразу же с верхней, а не по цепочке? Ведь нет никакой разницы, из какой таблицы берется, допустим, contract_id, они во всех таблицах одинаковы, т.к. мигрируют между всеми.
Для иллюстрации привожу две картинки, скажите, какая из них правильная?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.01.2015, 00:20
    #38864921
svnvlad
svnvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Идентифицирующие отношения, как правильно сделать миграцию ключей?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.01.2015, 00:23
    #38864924
svnvlad
svnvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Идентифицирующие отношения, как правильно сделать миграцию ключей?
Просто прописывать в SQL внешний ключ по одному полю вроде легче, чем один ключ сразу по нескольким полям.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.01.2015, 00:30
    #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:55
    #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:57
    #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, 03:50
    #38864982
R7
R7
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Идентифицирующие отношения, как правильно сделать миграцию ключей?
svnvlad,

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

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

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

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

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

У вас слишком вольные представления о миграции ключей. Это же не физическая возможность лепить ФК куда станет удобно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.01.2015, 10:16
    #38865133
R7
R7
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Идентифицирующие отношения, как правильно сделать миграцию ключей?
R7нарушить 4НФ
третью с половиной
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.01.2015, 11:20
    #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
| Ответить | Цитировать | Написать  
29.01.2015, 02:51
    #38866128
svnvlad
svnvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Идентифицирующие отношения, как правильно сделать миграцию ключей?
softwarersvnvladКогда стал рисовать, то задался вопросом: а если в самой нижней таблице есть часть ключа от самой верхней, то почему бы не связать ее сразу же с верхней, а не по цепочке? Ведь нет никакой разницы, из какой таблицы берется, допустим, contract_id, они во всех таблицах одинаковы, т.к. мигрируют между всеми.
Это не так.

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

Спасибо. Я это уже понял.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Идентифицирующие отношения, как правильно сделать миграцию ключей? / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 490ms
Закрыть
start [/forum/topic.php?fid=32&tablet=1&tid=1540662]:
 0ms
get settings:
 6ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 186ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 30ms
get tp. blocked users:
 1ms
others: 244ms
total:  490ms
x
x
Закрыть


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