следующие видео, будут практическими на тему как из ужасной базы привести ее к нормальному состаянию, а также на тему различных подходов к хранению данных, но эти видео сниму и выложу позже (не сегодня)
А вот в третем варианте, users_has_groups является связующим звеном между сущностями user и group. А если к примеру усложнить схему, и хранить в users_has_groups дату, когда пользователь вступил в группу, выходит что users_has_groups уже будет являться сущностью, и ей необходим PK ? Как быть в таком случае, делать PRIMARY_KEY(users_id, groups_id) или добавлять ID в сущность ? Зараннее спасибо за ответ, лайк - подписка - колокольчик ))
вот об этом я хотел чуть дальше рассказать, многие ORM требуют чтобы у сущности был PK и это была ОДНА колонка, но на самом деле PK может быть и составным (user_id и group_id). Поэтому если вы используете ORM удобней и проще добавить новую колонку с ID и таблицу user_has_group рассматривать как отдельную сущность со связями 1xN на user и group, но с точки зрения проектирования бд этого делать не обязательно, это просто определенные ограничения ORM, очень мало ORM без таких ограничений.
для просмотра существующей базы я использую возможности ide jetbrains по визуализации если нужно строить базу на основе отношений то mysql workbeanch, sql architect, ponyorm и тд. я хотел сделать следующее видео с практической точки зрения как это применять, но руки не доходят
насколько я помню линия без пунктира рисуется в случае если foreign key является primary key или его часть. то что вы говорить что комментарий не может существовать без новости, это верно, но реализуется как news_id NOT NULL, а на схеме nullable и not null колонки отображаются по другому. ну и опять же разные инструменты могут использовать разные способы визуализации
слева может быть таблица быть всегда пустой, а в правой таблице может быть добавлена новость 1 тогда у новость 1 будет 0 комментариев (нет комментариев) а потом вставят запись и привяжут к первой новости вот и появились комментарии у этой новости. это тип связи один ко многим и под многим может быть и 0
Спасибо за понятные и нужные пояснения!
Спасибо большое! Очень понятно объяснили. Будем теперь практиковаться:)
Спасибо, очень понятно, пригодилось для диплома.
Спасибо, очень полезно
Спасибо, всё понятно !
хорошее объяснение. спасибо большое
Спасибо большое!
Интересно спасибо!!!
Полезная инфа
Спасибо большое)
рад что понравилось, надеюсь до делаю видео дальше.
Спасибо!
Хорошая речь
ты мне помог автор Спасибо!
следующие видео, будут практическими на тему как из ужасной базы привести ее к нормальному состаянию, а также на тему различных подходов к хранению данных, но эти видео сниму и выложу позже (не сегодня)
у меня два пасспорта)
Спасибо
4 :D
А вот в третем варианте, users_has_groups является связующим звеном между сущностями user и group. А если к примеру усложнить схему, и хранить в users_has_groups дату, когда пользователь вступил в группу, выходит что users_has_groups уже будет являться сущностью, и ей необходим PK ? Как быть в таком случае, делать PRIMARY_KEY(users_id, groups_id) или добавлять ID в сущность ? Зараннее спасибо за ответ, лайк - подписка - колокольчик ))
вот об этом я хотел чуть дальше рассказать, многие ORM требуют чтобы у сущности был PK и это была ОДНА колонка, но на самом деле PK может быть и составным (user_id и group_id).
Поэтому если вы используете ORM удобней и проще добавить новую колонку с ID и таблицу user_has_group рассматривать как отдельную сущность со связями 1xN на user и group, но с точки зрения проектирования бд этого делать не обязательно, это просто определенные ограничения ORM, очень мало ORM без таких ограничений.
Спасибо ! Не подскажешь какой нибудь софт, для визуализации проектирования сущностей под линукс ?
для просмотра существующей базы я использую возможности ide jetbrains по визуализации
если нужно строить базу на основе отношений то mysql workbeanch, sql architect, ponyorm и тд.
я хотел сделать следующее видео с практической точки зрения как это применять, но руки не доходят
Evgeniy Kuvshinov ждем)
Сделайте урок про нормальные формы
Почему связь между сущностями comments (комментарий) и news (новости) пунктирная? Комментарий к новости же не может существовать без самой новости?
насколько я помню линия без пунктира рисуется в случае если foreign key является primary key или его часть.
то что вы говорить что комментарий не может существовать без новости, это верно, но реализуется как news_id NOT NULL, а на схеме nullable и not null колонки отображаются по другому.
ну и опять же разные инструменты могут использовать разные способы визуализации
Иногда появляется ощущение, будто говорит тимати :D
У вас ошибка на 3:38. Слева 1 или множество, а говорите "может и не быть комментариев". Говорите правильно, а вот графически Э-0---l- так должно быть.
слева может быть таблица быть всегда пустой, а в правой таблице может быть добавлена новость 1
тогда у новость 1 будет 0 комментариев (нет комментариев)
а потом вставят запись и привяжут к первой новости вот и появились комментарии у этой новости.
это тип связи один ко многим и под многим может быть и 0
Нифига не понял
тема белых кругляшочков и примари кеев не раскрыта...........
Непонятно
Спасибо. Очень полезно