|
|
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Такая задача: Есть люди, есть страны, каждый человек может поехать во много стран и в каждую страну могут поехать разные люди. Необходимо также хранить дату начала поездки и количество дней в поездке. Делаю таблички: 1. Person *id fullName ... 2. Country *id name ... 3. PersonToCountry *personId *countryId *startDate *qtyDate Вопрос: третья таблица является развязочной и по идее должен быть составной первичный ключ personId+countryId, но так как человек может ездить в одну и ту же страну много раз, то только эти два поля не будут давать уникальность. Хорошо ли делать составной ключ из всех 4х полей или это плохая практика? Может есть какой-то более хороший способ для таких ситуации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 14:13 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
lsk, хотите уникальность - сделайте(период пребывания и тп), первичный ключ здесь не причём. добавьте Id int identity primery key Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 14:24 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
lsk Хорошо ли делать составной ключ из всех 4х полей или это плохая практика? Нормальная практика, почему нет. Ключ доложен включать столько полей, сколько нужно для уникальности (другой вопрос что имхо в Вашем случае достаточно 3х полей - вряд ли могут быть 2 поездки в одну и ту же страну одного и того же человека с разным количеством дней, начинающиеся в одну и ту же дату). Если Вы планируете активно ссылаться на эту таблицу - можно первичным ключом сделать суррогат, но это скорее техническое, чем концептуальное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 15:24 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинНормальная практика, почему нет. Потому что дата и продолжительность поездки имеют привычку иногда меняться. А меняющийся ПК это та ещё забава. Неясно зачем вообще этой таблицу ПК. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 15:37 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
lskТакая задача: Есть люди, есть страны, каждый человек может поехать во много стран и в каждую страну могут поехать разные люди. Необходимо также хранить дату начала поездки и количество дней в поездке. Делаю таблички: 1. Person *id fullName ... 2. Country *id name ... 3. PersonToCountry *personId *countryId *startDate *qtyDate Вопрос: третья таблица является развязочной и по идее должен быть составной первичный ключ personId+countryId, но так как человек может ездить в одну и ту же страну много раз, то только эти два поля не будут давать уникальность. Хорошо ли делать составной ключ из всех 4х полей или это плохая практика? Может есть какой-то более хороший способ для таких ситуации? Если предположить, что Вы говорите о "Проектировании баз данных" (так называется этот форум), а не о проектировании реляционных баз данных, то Вы серьезно заблуждаетесь. То, что Вы (по неизвестной причине) называете "развязочной таблицей", это точно такой же тип сущности, как и Страна или Человек. Назовем его Поездка. Идентифицироваться экземпляры этого типа сущности должны точно так же, как и экземпляры типа сущности Человек и экземпляры типа сущности Страна. Идентификатором. Который не может быть свойством типа сущности, потому что должен представлять сущность независимо от значений ее свойств. Поэтому: уберите *id из Человека, *id из Страны, *personId и *countryId из Поездки. И у Вас все встанет на свои места. Используйте для начала М2 из учебного пособи "DB specific ORM", которое мы здесь подготовили общими усилиями, если хотите научиться проектировать базы данных. Если же речь идет о "проектировании реляционных баз данных", то верните тему в форум "Microsoft SQL Server" ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 17:16 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
БредятинаИдентифицироваться экземпляры этого типа сущности должны точно так же, как и экземпляры типа сущности Человек и экземпляры типа сущности Страна. Идентификатором. Поэтому: уберите id из Человека, id из Страны, personId и countryId из Поездки. Да, да, уберите идентификаторы из этих сущностей, поскольку в настоящих БД сущности связываются телепатически. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 18:03 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинв Вашем случае достаточно 3х полей - вряд ли могут быть 2 поездки в одну и ту же страну одного и того же человека с разным количеством дней, начинающиеся в одну и ту же дату согласен, не может такого быть, хватит и три поля. Dimitry Sibiryakov Потому что дата и продолжительность поездки имеют привычку иногда меняться. А меняющийся ПК это та ещё забава эти данные точно не будут меняться Dimitry SibiryakovНеясно зачем вообще этой таблицу ПК. а как это совсем без ключа? а если будет очень много записей и потом будут тормозить запросы или надо какие-то индексы строить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 19:23 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovКот МатроскинНормальная практика, почему нет. Потому что дата и продолжительность поездки имеют привычку иногда меняться. А меняющийся ПК это та ещё забава. "Имеют привычку меняться" - это, мягко говоря, неочевидно, но даже допустим. Если на таблицу нет ссылок - меняющийся ПК не приносит вообще никаких неудобств. Если ссылки есть (какие-нибудь билеты привязываем к поездке, командировочные, etc.) -то я не вижу специфики у полей "дата" и "количество дней" в этом плане. Если Иванов летал в Анголу не 11 ноября, а 3 марта - это та же сама поездка, а если Иванов 11 марта летал не в Анголу а в ЮАР - то поездка очевидно другая? Или наоборот? А почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 19:28 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
lskа если будет очень много записей и потом будут тормозить запросы или надо какие-то индексы строить? Тогда надо будет анализировать конкретные запросы и конкретно смотреть почему они конкретно тормозят. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 19:30 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинЕсли Иванов летал в Анголу не 11 ноября, а 3 марта - это та же сама поездка, а если Иванов 11 марта летал не в Анголу а в ЮАР - то поездка очевидно другая? Или наоборот? А почему? Вот именно это и есть вопрос: почему данные поля вообще тобой рассматриваются как идентифицирующие? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 19:40 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Потому что других полей у этой сущности нет :) И если вообще стоит задача идентифицировать поездки - это надо делать по этим полям, а не потому что "в системе у них один и тот же гуид" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 20:00 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Задача стоит потом вывести список людей + страна + количество поездок в данную страну + суммарное количество дней поездок в данную строну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 22:26 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за ответы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2016, 13:15 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинЕсли Вы планируете активно ссылаться на эту таблицу - можно первичным ключом сделать суррогат, но это скорее техническое, чем концептуальное решение. я бы добавил в PersonToCountry свой id по аналогии как у первых двух таблиц, забыл и никогда больше не парился по этому поводу... и ссылаться потом можно (в перспективе, о которой многие по началу даже не подозревают) и обрабатывать удобно (ты ведь стоишь на конкретной id) не нужно думать о том, что при удалении или корректировке зацепишь ещё несколько похожих записей и не нужно тащить в составной ключ все поля таблицы (маразм) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2016, 13:29 |
|
||
|
связь многие ко многим много раз
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovБредятинаИдентифицироваться экземпляры этого типа сущности должны точно так же, как и экземпляры типа сущности Человек и экземпляры типа сущности Страна. Идентификатором. Поэтому: уберите id из Человека, id из Страны, personId и countryId из Поездки. Да, да, уберите идентификаторы из этих сущностей, поскольку в настоящих БД сущности связываются телепатически. Да, идентификаторы не являются свойствами сущностей, стыдно этого не знать))) В БД (любых) сущности связываются связями. А вот в не БД они связываются, вероятно, как придется, в зависимости от особенностей системы. Поэтому и следует вернуть эту тему в "Microsoft SQL Server", раз речь идет не о базах данных))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2016, 16:14 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=39190823&tid=1540379]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 154ms |

| 0 / 0 |

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