powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / связь многие ко многим много раз
15 сообщений из 15, страница 1 из 1
связь многие ко многим много раз
    #39190544
lsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lsk
Гость
Такая задача: Есть люди, есть страны, каждый человек может поехать во много стран и в каждую страну могут поехать разные люди. Необходимо также хранить дату начала поездки и количество дней в поездке.

Делаю таблички:
1. Person
*id
fullName
...

2. Country
*id
name
...

3. PersonToCountry
*personId
*countryId
*startDate
*qtyDate

Вопрос: третья таблица является развязочной и по идее должен быть составной первичный ключ personId+countryId, но так как человек может ездить в одну и ту же страну много раз, то только эти два поля не будут давать уникальность. Хорошо ли делать составной ключ из всех 4х полей или это плохая практика? Может есть какой-то более хороший способ для таких ситуации?
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190549
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lsk,

хотите уникальность - сделайте(период пребывания и тп), первичный ключ здесь не причём. добавьте Id int identity primery key

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190572
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lsk Хорошо ли делать составной ключ из всех 4х полей или это плохая практика?
Нормальная практика, почему нет. Ключ доложен включать столько полей, сколько нужно для уникальности (другой вопрос что имхо в Вашем случае достаточно 3х полей - вряд ли могут быть 2 поездки в одну и ту же страну одного и того же человека с разным количеством дней, начинающиеся в одну и ту же дату).
Если Вы планируете активно ссылаться на эту таблицу - можно первичным ключом сделать суррогат, но это скорее техническое, чем концептуальное решение.
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190577
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинНормальная практика, почему нет.
Потому что дата и продолжительность поездки имеют привычку иногда меняться. А меняющийся ПК это та ещё забава.

Неясно зачем вообще этой таблицу ПК.
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190600
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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" )))
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190620
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаИдентифицироваться экземпляры этого типа сущности должны точно так же, как
и экземпляры типа сущности Человек и экземпляры типа сущности Страна. Идентификатором.

Поэтому: уберите id из Человека, id из Страны, personId и countryId из Поездки.
Да, да, уберите идентификаторы из этих сущностей, поскольку в настоящих БД сущности
связываются телепатически.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190654
lsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lsk
Гость
Кот Матроскинв Вашем случае достаточно 3х полей - вряд ли могут быть 2 поездки в одну и ту же страну одного и того же человека с разным количеством дней, начинающиеся в одну и ту же дату
согласен, не может такого быть, хватит и три поля.

Dimitry Sibiryakov Потому что дата и продолжительность поездки имеют привычку иногда меняться. А меняющийся ПК это та ещё забава
эти данные точно не будут меняться

Dimitry SibiryakovНеясно зачем вообще этой таблицу ПК.
а как это совсем без ключа? а если будет очень много записей и потом будут тормозить запросы или надо какие-то индексы строить?
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190656
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovКот МатроскинНормальная практика, почему нет.
Потому что дата и продолжительность поездки имеют привычку иногда меняться. А меняющийся ПК это та ещё забава.

"Имеют привычку меняться" - это, мягко говоря, неочевидно, но даже допустим. Если на таблицу нет ссылок - меняющийся ПК не приносит вообще никаких неудобств. Если ссылки есть (какие-нибудь билеты привязываем к поездке, командировочные, etc.) -то я не вижу специфики у полей "дата" и "количество дней" в этом плане. Если Иванов летал в Анголу не 11 ноября, а 3 марта - это та же сама поездка, а если Иванов 11 марта летал не в Анголу а в ЮАР - то поездка очевидно другая? Или наоборот? А почему?
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190659
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lskа если будет очень много записей и потом будут тормозить запросы или надо
какие-то индексы строить?
Тогда надо будет анализировать конкретные запросы и конкретно смотреть почему они
конкретно тормозят.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190662
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинЕсли Иванов летал в Анголу не 11 ноября, а 3 марта - это та же сама
поездка, а если Иванов 11 марта летал не в Анголу а в ЮАР - то поездка очевидно другая?
Или наоборот? А почему?
Вот именно это и есть вопрос: почему данные поля вообще тобой рассматриваются как
идентифицирующие?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190671
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

Потому что других полей у этой сущности нет :) И если вообще стоит задача идентифицировать поездки - это надо делать по этим полям, а не потому что "в системе у них один и тот же гуид"
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190714
lsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lsk
Гость
Задача стоит потом вывести список людей + страна + количество поездок в данную страну + суммарное количество дней поездок в данную строну.
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190823
lsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lsk
Гость
Всем спасибо за ответы.
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190826
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинЕсли Вы планируете активно ссылаться на эту таблицу - можно первичным ключом сделать суррогат, но это скорее техническое, чем концептуальное решение.

я бы добавил в PersonToCountry свой id по аналогии как у первых двух таблиц, забыл и никогда больше не парился по этому поводу... и ссылаться потом можно (в перспективе, о которой многие по началу даже не подозревают) и обрабатывать удобно (ты ведь стоишь на конкретной id) не нужно думать о том, что при удалении или корректировке зацепишь ещё несколько похожих записей и не нужно тащить в составной ключ все поля таблицы (маразм)
...
Рейтинг: 0 / 0
связь многие ко многим много раз
    #39190884
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovБредятинаИдентифицироваться экземпляры этого типа сущности должны точно так же, как
и экземпляры типа сущности Человек и экземпляры типа сущности Страна. Идентификатором.

Поэтому: уберите id из Человека, id из Страны, personId и countryId из Поездки.
Да, да, уберите идентификаторы из этих сущностей, поскольку в настоящих БД сущности
связываются телепатически.

Да, идентификаторы не являются свойствами сущностей, стыдно этого не знать)))
В БД (любых) сущности связываются связями. А вот в не БД они связываются, вероятно, как придется, в зависимости от особенностей системы. Поэтому и следует вернуть эту тему в "Microsoft SQL Server", раз речь идет не о базах данных)))
...
Рейтинг: 0 / 0
15 сообщений из 15, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / связь многие ко многим много раз
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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