Андрей, добрый день. Все, что вы объясняете - очень понятно и максимально подробно изложено. Я сейчас изучаю предмет "Базы данных", и это очень помогает. Однако, начинается предмет именно с проектирования баз данных, а потом уже с работой с базами данных в СУБД. Скажите пожалуйста, у вас в планах нет разбора темы проектирования баз данных, нормализации баз данных? Вы упомянули о том, что это отдельная тема, и в этом курсе она разбираться не будет. Я думаю, что для многих она была бы очень актуальной, потому что такого объяснения, как даете вы, по этой теме на просторах интернета я еще не встретил. Или, может вы знаете, куда обратиться (к каким материалам), для изучения именно проектирования баз данных на начальном уровне (от первой до третьей нормальной формы). Я вам заранее благодарен за любой ответ.
На мой взгляд, довольно не корректно делать в таблице с фильмами столбец с ID супергероя, так как в фильме их может быть несколько и будут встречаться дубли и при большом количестве столбцов это большая проблема. Однако в таблице с супергероями делать столбец с ID фильма тоже странно, так как супергерой может мелькать в множестве фильмов. Самое идеальное решение сделать отдельную таблицу, где будут ID супергероев и ID фильмов, которую уже можно приджоинить к таблице с фильмами если нужно узнать в каком фильме были какие супергерои, либо к таблице с героями, чтобы узнать в каких фильмах был какой-то супергерой.
Тип связи между супергероями и фильмами - многие ко многим. Стандартный подход к представлению связей такого типа в реляционной базе: создание дополнительной таблицы, которая будет содержать только два столбца: идентификаторы связанных сущностей. Так что вы все правильно написали.
Благодарю за видео! Вопрос: не логичнее добавить внешний ключ на таблицу с фильмами в таблицу с супергероями, ведь в одном фильме, скажем с Человеком Пауком, могут быть разные супергерои/злодеи. В примере из видео получается, что либо в фильме присутствует один единственный супергерой, либо в таблице фильмы строки с фильмами будут дублироваться кратно числу героев, которые есть в этих фильмах. Или я не прав?
да не важно. это лишь демонстрация возможностей, конкретную задачу ставят на предприятии бизнес-аналитики, или же они сами создают. наша задача научиться оперировать синтаксисом языка
@@ВладимирТемченко-1993 Вам не важно, а мне важно - хочется не только с синтаксисом разобраться, но научиться строить правильную логику в отношении нормализации таблиц в БД.
В следующей лекции прямо в заголовке ключевое слово JOIN. Именно JOIN’ы на начальном этапе вызывают больше всего проблем и непонимания. Наверное, поэтому смотрят больше. И, скорее всего, в поиске выдаётся чаще из-за популярного ключевого слова.
Связь не корректная. Правильная связь многие ко многим, и делается она с помощью вспомогательной таблицы. Некорректная связь в видео потому, что в одном фильме может быть несколько героев
Самый супергеройский курс по SQL, который я видел! 😎
Спасибо 🦸♂️
Плюсую за дисциплину "проектирование БД" . Так интересно!!!!
Андрей, большое спасибо за теорию и объяснения! Очень доволен Вашим курсом!
Пожалуйста! Рад, что курс понравился!
Спасибо, доступно и хорошо обьясняете
Спасибо! Вы очень доступно объясняете.
Пожалуйста! Рад, что нравится!
Просто прекрасное изложение. Спасибо
Пожалуйста. Рад, что понравилось!
У Андрея отличные курсы, давно пора выходить на Степик)) имхо
нравится заниматься по вашим урокам. спасибо
Спасибо Вам, Андрей)
Андрей, добрый день. Все, что вы объясняете - очень понятно и максимально подробно изложено. Я сейчас изучаю предмет "Базы данных", и это очень помогает. Однако, начинается предмет именно с проектирования баз данных, а потом уже с работой с базами данных в СУБД. Скажите пожалуйста, у вас в планах нет разбора темы проектирования баз данных, нормализации баз данных? Вы упомянули о том, что это отдельная тема, и в этом курсе она разбираться не будет. Я думаю, что для многих она была бы очень актуальной, потому что такого объяснения, как даете вы, по этой теме на просторах интернета я еще не встретил. Или, может вы знаете, куда обратиться (к каким материалам), для изучения именно проектирования баз данных на начальном уровне (от первой до третьей нормальной формы). Я вам заранее благодарен за любой ответ.
спасибо большое!Очень хороший курс!
Дякую за корисний контент :)
Отличный курс! Еще бы курс по решению задач)
Полезное видео, спасибо.
Пожалуйста!
Отличное видео! Как всегда, очень ясно и наглядно, спасибо!
На мой взгляд, довольно не корректно делать в таблице с фильмами столбец с ID супергероя, так как в фильме их может быть несколько и будут встречаться дубли и при большом количестве столбцов это большая проблема. Однако в таблице с супергероями делать столбец с ID фильма тоже странно, так как супергерой может мелькать в множестве фильмов. Самое идеальное решение сделать отдельную таблицу, где будут ID супергероев и ID фильмов, которую уже можно приджоинить к таблице с фильмами если нужно узнать в каком фильме были какие супергерои, либо к таблице с героями, чтобы узнать в каких фильмах был какой-то супергерой.
Тип связи между супергероями и фильмами - многие ко многим. Стандартный подход к представлению связей такого типа в реляционной базе: создание дополнительной таблицы, которая будет содержать только два столбца: идентификаторы связанных сущностей. Так что вы все правильно написали.
Спасибо познавательно )
Пожалуйста!
Но одном фильме может быть много героев, как и один герой может быть в многих фильмах. Many to many тут лучше подойдет)
Благодраствую
Огромное спасибо вам Андрей! Подскажите пожалуйста, что можно почитать или посмотреть по проектированию баз данных?
Спасибо!
Пожалуйста!
Было бы еще неплохо пояснить про ON DELETE и ON UPDATE
Лайк
Спасибо!
Так а почему не показали как сделать внешний ключ?
Благодарю за видео!
Вопрос: не логичнее добавить внешний ключ на таблицу с фильмами в таблицу с супергероями, ведь в одном фильме, скажем с Человеком Пауком, могут быть разные супергерои/злодеи. В примере из видео получается, что либо в фильме присутствует один единственный супергерой, либо в таблице фильмы строки с фильмами будут дублироваться кратно числу героев, которые есть в этих фильмах. Или я не прав?
да не важно. это лишь демонстрация возможностей, конкретную задачу ставят на предприятии бизнес-аналитики, или же они сами создают. наша задача научиться оперировать синтаксисом языка
@@ВладимирТемченко-1993 Вам не важно, а мне важно - хочется не только с синтаксисом разобраться, но научиться строить правильную логику в отношении нормализации таблиц в БД.
Интересно как пляшет количество просмотров от лекции к лекции. Даже базовый курс смотрят выборочно? Или почему у следующей просмотров больше?
В следующей лекции прямо в заголовке ключевое слово JOIN. Именно JOIN’ы на начальном этапе вызывают больше всего проблем и непонимания. Наверное, поэтому смотрят больше.
И, скорее всего, в поиске выдаётся чаще из-за популярного ключевого слова.
Связь не корректная. Правильная связь многие ко многим, и делается она с помощью вспомогательной таблицы. Некорректная связь в видео потому, что в одном фильме может быть несколько героев
Чёт как-то без примеров
ууу. мутная тема эти джойны. я всю голову сломал
Про джойны будет несколько видео. Надеюсь, все будет понятно 😉
Union-ы ещё мутнее, особенно когда крупные таблицы
Union достаточно редко используется на практике, в отличие от JOIN.
Не соглашусь, union используется на практике уж не реже джоинов точно, а то и чаще
СПАСИБО!!!