Практический курс по SQL для начинающих - #6 Проектирование и нормализация Базы Данных (БД)

Данный курс на YouTube - сильно укороченная (демо) версия полного курса, который вы можете приобрести на stepik (с карточкой из РФ) или Udemy (с карточкой не из РФ)

Купить полный курс на stepik:

Купить полный курс на udemy:

---------------------------------------------------------------------------------------------

Базы данных (БД) вообще и реляционные базы данных в частности - очень широкие темы. Эта серия уроков по SQL посвящена именно разработке реляционных баз данных под управлением PostgreSQL (PostgreSQL - это СУБД т.е. система управления базами данных).

На этом курсе по SQL вы освоите основы SQL: узнаете что такое SQL, научитесь писать SQL запросы различной сложности. Все те знания, которые вы получите на курсе легко применимы и к другим СУБД, таким как MySQL, Microsoft SQL Server, Oracle.

Изучение SQL это один из самых быстрых способов подняться по карьерной лестнице и начать зарабатывать ещё больше. На курсе вы будете учиться и получать задания для собственной проверки и улучшения понимания материала.

В данном видео уроке по SQL мы разбираем:

00:00 Введение в процесс проектирование базы данных (БД)
18:13 Рекомендации, лучшие и худшие практики по проектированию базы данных (БД)
26:59 Нормальные формы и нормализация базы данных (БД): первая нормальная форма, вторая нормальная форма, третья нормальная форма

#sql #postgresql #engineerspock

[prometey]

Чувак, у тебя талант истинного преподавателя - объяснять сложные вещи простым языком. Только за это купил твой курс на Степико. Молодец.

[sandushaikhina]

Сколько я пыталась найти нормальные курсы по sql... у тебя талант к преподаванию. Спасибо огромное!!!

[mikhailurtamov]

Автору большая благодарность за труд!
Материал подаётся очень доходчиво, что сохраняет желание продолжать обучение дальше.

В программировании абсолютный новичек, пока искал за что зацепиться перебрал достаточно языков программирования и курсов к ним. Скажу, что именно курсы Ильи остановили этот перебор и помогли сосредоточиться на чем-то конкретном: БД и C#. Ещё раз спасибо за труд!!!

[MayorKozin]

Комментарий в поддержку! Огромное спасибо, для аналитика знаний в лекциях достаточно для понимания азов в работе с БД!

[gnompirogov]

Спасибо большое!!! С удовольствием смотрю

[АлександраМм]

Спасибо за интересный, понятныйи хорошо структурированный курс! 👍

[HeIvis]

Это конечно очень круто, настолько ясно и понятно. А то читаю книгу: Основы технологий баз данных (Новиков), он так сложно описал

[slunmuo]

Спасибо! Наконец-то всё стало понятно)

[arthurpralaya]

В принципе все правильно рассказано, но хотел бы добавить, что касается вычислимых полей, что это не такая уж и плохая практика, как раз иногда она очень даже нехило выручает по производительности. Например, у вас есть сущность товары и у них есть свойство рейтинг, и раз в сутки вы запускаете скрипт, который пересчитывает рейтинги этих товаров, например, на основе частоты покупок или просмотров этих товаров. Этот самый рейтинг будет логично здесь сделать вычислимым полем, просто чтобы не рассчитывать его каждый раз при вызове метода получения значения этого рейтинга.
Update: собственно, автор чуть позже как раз об этом и рассказал)

[root]

Не думаю, что Фёдор Достоевский - идиот, а в целом, очень полезный видеоматериал

[ВалерийЛебедев-ес]

До твоих видео читал книгу Основы языка SQL Е.Моргунов
появился вопрос по поводу скалярности и простых типов
В книге есть пример использования json строки:
Предметная область - авиаперелеты
Таблица - самолет
Поле - Характеристики самолета, тип - json
Дело в том что в книге объясняется этот пример тем, что список характеристик у самолетов может быть разным, а также при появлении новых типов характеристик для самолета, нам не нужно менять структуру таблицы.
Вот собственно и вопрос: В таком случае будут ли соблюдаться условия 1НФ? и если нет то почему вариант с разделением этой json строки на поля более предпочтителен?

[FrostyLD]

С ИНН пример всё-таки некорректен - это уникальная штука. Согласно приказу ФНС "ИНН, признанный недействительным, не может быть присвоен другой организации (другому физическому лицу)."

[EngineerSpock]

Данный курс на YouTube - сильно укороченная (демо) версия полного курса, который вы можете приобрести на stepik (с карточкой из РФ) или Udemy (с карточкой не из РФ)

Купить полный курс на stepik:

Купить полный курс на udemy:

[Nodorgrom]

40:30 я так понимаю если book_title вынести в отдельную табличку с book_title_id, book_title с book_title_id как внешний ключ на books.book_title_id, то мы получим 4НФ ?))

[NoNaMe-ldq]

первые 2/3 видео - вода из специфических терминов, что делает бесполезным для тех, кто только вникает в СУБД. А вот последняя часть оказалась очень даже полезной.

p.s. В конце правда сильно не хватает скрина со всеми рассматриваемыми таблицами

[RaptorTV]

17:48 послышалось как "это normal shit"

[beatrixx_kiddo]

Я не совсем поняла. на 32:38 вы говорите, что композитный ключ был бы уникальным даже если бы повторялись имена author_id, book_id. Но ведь если 2 раза будет книга Льва Толстого "Война и мир", то составной ключ тоже повторится и тогда уже не будет уникальным.

[ganjaph]

не знаю как там на россии но в Украине ИНН всегда уникален и вычисляется исходя из личных данных человека которому его присваивают. Не бывает двух одинаковых ИНН. По этому не совсем согласен с этим примером, но логика ясна - ключ должен быть немутабелен и уникален.

[EdwardNorthwind]

Не знаю будет ли об этом сказано дальше, поэтому спрошу сразу. Индексы для FOREIGN KEY не создаются, но в чем разница между:
CREATE INDEX
ON public.reports (create_employee_id, update_employee_id);
и
CREATE INDEX ON public.reports (create_employee_id);
CREATE INDEX ON public.reports (update_employee_id);