ReSQL.ru
     
powered by simpleCommunicator - 2.0.46     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как лучше организовывать связи между Свойствами
12 сообщений из 12, страница 1 из 1
Как лучше организовывать связи между Свойствами
    #39979837
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Добрый день Товарищи!

Заголовк сформулирован коряво, т.к. непонятно как это сформулировать в строку.

Итого:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
# 1. Есть Участники
Table Users (
      ID    SERIAL PK,
      ...............
)

# 2. Есть языки программирования
Table Langs (
      ID    SERIAL PK,
      ...............
)

# 3. Участники владеют разными языками
Table UserLangs (
      FK(userID) => Users(id),
      FK(LangID) => Langs(id),
      UNIQUE (UserID, LangID) 
)

# 4. Есть КОМНАТЫ
Table Rooms (
      ID    SERIAL PK,
      ...............
)

# 5. Участники сидят в Комнатах
Table UserRoom (
     FK(RoomID) => Rooms(id),
     FK(UserD) => Users(id)
)

# 6. И в Комнатах Участники заявлены на ЯП.
Table UserRoomLangs (
     FK(UR_ID) => UserRoom(id),
     FK(UL_ID) => UserLangs(id)
)



Собственно весь вопрос по 6 таблице в которой хранить Языки которые пользователь использует в комнате.
* Т.е. набор языков пользователя в комнате должен быть подмножеством языков которыми он владеет (не обязательно все)

И если реализовывать по FK на таблицу UserLangs, то везде в запросах для проверки соответствия ЯЗЫКА, ПОЛЬЗОВАТЕЛЯ, КОМНАТЫ появляются дополнительные JOIN'ы.
Код: sql
1.
2.
3.
4.
5.
6.
.....
JOIN   UserRoom        a1 ON a1.RoomID=...
JOIN   UserRoomLangs   b1 ON b1.UR_ID=a1.id
JOIN   UserLangs       c1 ON c1.id=b1.UL_ID
WHERE  c1.UserID = ...
  AND  c1.LangID = ...



А если реализовать таким типом
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Table UserRoom (
     FK(RoomID) => Rooms(id),
     FK(UserD) => Users(id)
)

Table UserRoomLangs (
     FK(RoomID) => Rooms(id),
     FK(UserD) => Users(id),
     FK(LangD) => Langs(id)
)



то вроде связность данных страдает. И смысл в том, что глубина таких связей может быть больше чем тут описано. Такой тип задачи как в БД правильно спроектировать?
...
Рейтинг: 0 / 0
15.07.2020, 12:08
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979842
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
kormot,

опишите кратко предметную область: в чём участвуют люди, что за комнаты такие и зачем участники там сидят?
...
Рейтинг: 0 / 0
15.07.2020, 12:15
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979910
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Дмитрий Мух , предметная область вообще не про Участников, Комнаты и Языки :) Просто терминологией настоящих сущностей чтобы понять смысл и связи - это надо будет описывать более широкий круг Сущностей, что совсем бессмысленно :)

Смысл описывается математически вроде понятно, в моём посте. Но могу ещё так расписать:
1. Участники - это "Корневая Сущность"
2. Комнаты - это "Корневая Сущность"
3. Язык - это "Корневая Сущность"

1. Участники имеют связь "Один ко Многим" к Языкам ( UL_ID ). Это значит, что Участник владеет данным набором Языков.
2. Участники имеют связь "Один ко Многим" к Комнатам. Это значит, что Участник может состоять в Комнатах (да, единомоментно в нескольких)
3. В каждой Комнате Участник ( UR_ID ) может Пользоваться неким набором Языков ( UL_ID ) пересекающимся с ЯзыкамиКоторымиВладеетУчастник

Собственно вопрос в том, реализовывать связь Языков Участников в Комнатах в виде ( UR_ID, UL_ID ) или в виде (userID, roomID, langID)

Подразумевается, что Языки Пользователя как записи UL_ID не удаляются. Т.е. каскадно все ссылки на UL_ID НЕ удаляются.
...
Рейтинг: 0 / 0
15.07.2020, 13:36
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979913
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
kormot
Такой тип задачи как в БД правильно спроектировать?

Чтобы ответить, нужно прочитать толковое описание задачи (а не попытки её решения). По приведённому я бы сказал, что наблюдается явная избыточность сущности UserRoom, её нужно просто выкинуть вместе с создаваемыми ей проблемами.
...
Рейтинг: 0 / 0
15.07.2020, 13:41
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979919
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
kormot
В каждой Комнате Участник ( UR_ID ) может Пользоваться неким набором Языков ( UL_ID ) пересекающимся с ЯзыкамиКоторымиВладеетУчастник

Пересекающимися, или только теми, которыми владеет?
И "может пользоваться" и "владеет" - тоже давольно-таки разные вещи.

Вообщем исходя из того описания, что вы предоставили, я склоняюсь к варианту: userID, roomID, langID.
...
Рейтинг: 0 / 0
15.07.2020, 13:46
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979925
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
softwarer
её нужно просто выкинуть вместе с создаваемыми ей проблемами.

ок, подумаю на этот счёт. А каким образом хранить присутсвие Участника в Комнате хранить?

По поводу описания чего надо, а не как решил:
Надо иметь возможность Объекту1 (Участнику) ставить в соответствие подмножество Объектов2 (Языки) в разрезе Объектов3 (Комнаты).
И это множество Объектов2 в разрезе Объектов3 ( Языки Пользователя в Комнате ) должно всегда быть подмножеством одного множества Объектов2 (Языков которыми в принципе владеет Участник).

Рекурсия она рекурсивная :)
...
Рейтинг: 0 / 0
15.07.2020, 13:53
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979927
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Дмитрий Мух
Пересекающимися, или только теми, которыми владеет?
И "может пользоваться" и "владеет" - тоже давольно-таки разные вещи.


Так я же на примере языков потому и описал, т.к. Участник может знать (владеть) Язык, но в определённом месте (Комната) пользоваться набором языков и пустым тоже (NULL => Молчать) которое при любом раскладе будет подмножеством ЯзыковКоторымиОнВладеет.
...
Рейтинг: 0 / 0
15.07.2020, 13:57
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979946
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
kormot
Дмитрий Мух
Пересекающимися, или только теми, которыми владеет?
И "может пользоваться" и "владеет" - тоже давольно-таки разные вещи.


Так я же на примере языков потому и описал, т.к. Участник может знать (владеть) Язык, но в определённом месте (Комната) пользоваться набором языков и пустым тоже (NULL => Молчать) которое при любом раскладе будет подмножеством ЯзыковКоторымиОнВладеет.

Изначально вы написали "языки программирования".

Пользоваться ими можно по-разному.
Можно использовать по полной в каждодневной работе, а можно время от времени что-то простенькое пописывать, какие-то небольшие вещи править.

К примеру не обязательно прям владеть YAML, чтобы им пользоваться.
Также можно владеть C# и при этом пользоваться примерами кода на Java

В резюме же никто не указывает все языки, которыми пользовался, как те, чем владеешь.
...
Рейтинг: 0 / 0
15.07.2020, 14:18
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39979949
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
kormot
А каким образом хранить присутсвие Участника в Комнате хранить?

Просматриваются несколько возможных решений. Можно решить, что безъязыкие участники не нужны. Можно сделать язык необязательным и хранить (участник; комната; null). Можно ввести спецязык "отсутствует". Можно придумать ещё что-нибудь. Что выбрать - зависит от конкретной бизнес-логики с этими объектами, не удастся назвать универсально лучшее решение.

kormot
Надо иметь возможность Объекту1 (Участнику) ставить в соответствие подмножество Объектов2 (Языки) в разрезе Объектов3 (Комнаты)

Это решает UserRoomLangs.

kormot
И это множество Объектов2 в разрезе Объектов3 ( Языки Пользователя в Комнате ) должно всегда быть подмножеством одного множества Объектов2 (Языков которыми в принципе владеет Участник).

Значит, из UserRoomLangs нужен внешний ключ на UserLangs.

Кажется, до меня дошла причина Вашего вопроса. Вы почему-то считаете, что внешний ключ - это ul_id. На самом же деле он может быть, и в подобных структурах часто удобнее - (user_id, lang_id).
...
Рейтинг: 0 / 0
15.07.2020, 14:25
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39980118
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Дмитрий Мух
Изначально вы написали "языки программирования".

Пользоваться ими можно по-разному.
Можно использовать по полной в каждодневной работе, а можно время от времени что-то простенькое пописывать, какие-то небольшие вещи править.

К примеру не обязательно прям владеть YAML, чтобы им пользоваться.
Также можно владеть C# и при этом пользоваться примерами кода на Java

В резюме же никто не указывает все языки, которыми пользовался, как те, чем владеешь.

Дмитрий, ну причём тут всё это, я же написал что это не более чем иллюстрация вопроса.

softwarer
Кажется, до меня дошла причина Вашего вопроса. Вы почему-то считаете, что внешний ключ - это ul_id. На самом же деле он может быть, и в подобных структурах часто удобнее - (user_id, lang_id).

Это уже попахивает очередным SQL откровением, т.е. это как использовать? Как составной внешний ключ описать?

softwarer
Просматриваются несколько возможных решений. Можно решить, что безъязыкие участники не нужны. Можно сделать язык необязательным и хранить (участник; комната; null). Можно ввести спецязык "отсутствует". Можно придумать ещё что-нибудь. Что выбрать - зависит от конкретной бизнес-логики с этими объектами, не удастся назвать универсально лучшее решение.

Тут может я так надавил на эти Языки, на самом деле Языки в Комнатах и у Пользователей это не единственная составляюшая этих свойств Участников относительно Комнат, я это просто привёл для иллюстрации задачи.

Все эти Комнаты и Языки завели отвечающих не туда. :)
...
Рейтинг: 0 / 0
15.07.2020, 19:39
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39980150
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
kormot
Как составной внешний ключ описать?

Уверен, что документация используемой СУБД даст чёткий и точный ответ на этот вопрос.
...
Рейтинг: 0 / 0
15.07.2020, 20:41
| Ответить | Цитировать | Написать  
Как лучше организовывать связи между Свойствами
    #39980253
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
softwarer в итоге это именно то что я и спрашивал! И в целом я зачастую заводил прокси таблицу для преобразования двух полей в новый ключ, а на самом-то деле вон как правильно.

Что за книжку прочитать по SQL чтобы эти все правила - то сразу и увидеть. А то вроде знаю и пользуюсь SQL'ем, а на деле оказывается что знаю лишь то, что ничего не знаю :)
...
Рейтинг: 0 / 0
16.07.2020, 09:35
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как лучше организовывать связи между Свойствами
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=3&tid=1539844]:
 0ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 24ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 46ms
get tp. blocked users:
 2ms
others: 233ms
total:  351ms
созд. / загр.: 351ms
x
x
Закрыть


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