Как хорошо, что есть люди, которым не лень внятно и на хорошем примере провести брифинг по основным понятиям, привести хинты и разбор часто возникающих ошибок так, чтобы это было приятно смотреть. Сам привык все узнавать из печатных источников, но данный плейлист в изобилии предоставляет всю необходимую информацию.
Владимир, доброго времени суток. Спасибо за видео. К сожалению, в видео есть две ошибки, вернее одна ошибки и неточность. Реляционные базы данных называются так не потому, что данные одной таблицы связаны с данными другой, а потому, что таблицы в реляционной БД являются представлением некого математического объекта отношения(Relation). Грубо говоря, отношения это сами таблицы, удовлетворяющие некоторому набору правил. А связи между таблицами лучше отношения не называть, чтобы избежать путаницы. Неточность состоит в том, что внешний ключ это, в первую очередь, ограничение целостности данных за которым следит сама СУБД. И если, например, попытаться удалить студента у которого есть предметы, то СУБД либо не даст этого сделать либо удалит соответствующие записи в таблице Ст_Пред. Кстати есть еще одна возможность, выставить в NULL значения ячейки в зависимой таблице, что в вместе с объявлением сложного первичного ключа в таблице связей приведет к ошибке, но для данного примера выставлять в NULL бессмысленно. Еще небольшое замечание, не стоит называть поля словом ключ, опять таки дабы избежать путаницы, лучше Ин(Идентификатор), и сказать что по этому полю создается ключ первичный (внешний) ключ, всё же ключи это слега отдельные от таблиц структуры. Еще раз огромное спасибо за видео, оно после прочтения нудных теоретических книжек позволяет "оживить" прочитанное.
Первичный ключ - это столбец в базе данных, где каждая строка имеет уникальное значение. Каждая таблица имеет только один первичный ключ. Значения NULL не допускаются. Уникальный ключ - это столбец или группа столбцов, которые вместе содержат уникальные значения. Таблица может иметь более одного уникального ключа. Например, в списке американских граждан столбец с номерами социального страхования будет первичным ключом, а столбцы имени и фамилии в сочетании с номером телефона - уникальным ключом.
Спасибо за видео. Очень хотелось бы увидеть видео, где объясняются базовые понятия реляционных баз данных в вашем представлении. Судя по вашим словам в вашем понимании термин "Отношение" не совпадает с соответствующим термином в теории реляционных БД, где я как я понимаю отношение есть сама таблица с определёнными условиями.
Anatoli Zaharenko вы правы, в РСУБД отношение это набор строк и столбцов. Это может быть как таблица, так и результат выборки из несколькиъ таблиц путем объединения (union), соединения (join), произведения (cross join) и т.д.
Отличный урок, Володя, спасибо! Но мне кажется, я бы не понял это, если бы у меня не было опыта в создании базы данных в Access. Я реализовывал это на практике, но не догадывался, вы же все поставили по полочкам.
Вот мне всё-таки интересно узнать. В книге Криса Файли "SQL" написано: "Имейте в виду, что прилагательное «реляционная» (relational), которое входит в название «реляционная база данных» (relational database), появилось благодаря математической «реляционной теории множеств» (relational set theory), а не из-за возможности устанавливать связь (to relate) между разными таблицами по их общим значениям." Так кому верить? Если тут и многие говорят, что "реляционная" от "устанавливать связь"? А в книге наоборот....
Здравствуйте! Большое спасибо за видео, очень доступно и максимально понятно. Подскажите пожалуйста, какой выбрать для изучения язык программирования. В данный момент работаю уже год в QA, хочу развиваться дальше в этой отросли. Спасибо
Володя привет, подскажите - я даже когда использую сложный ключ все равно в таблице делаю автоинерементное поле - как Вы считаете это верно или все же лишняя трата ресурса
+Sasha Gedz Я-бы не стал делать ещё одно поле. Когда программист видит таблицу где 2 внешних ключа формируют 1 сложный ключ, то сразу понимает в чём тут дело (связь много к многому). В том что вы делаете нет ничего плохого (количество затраченых ресурсов минимальное, не стоит волноваться если вы не вставляете что-то в эту таблицу миллионы раз в минуту), просто вы немного откланились от конвенций. Хотя вы можете найти себя работающим в компании где (например) есть правило, что все таблицы обязательно должны содержать только 1 ключевое поле, которое автоинкриментируется. И в такой организации ваш подход как раз будет "правильным" (даже единственно правильным).
Vladimir Mozhenkov Большое спасибо за полный ответ, я как раз отношусь к людям которые долго и упорно что-то делают потом видят другой поход и начинают сомневаться в правильности всего что они делали до этого =), с каждым днем Ваш канал все интереснее и все время есть что-то новое - еще раз спасибо!
добавим год в ДР? а какого типа ДР? если это дата, то там уже есть год. не дата? нарушение 1НФ? непонятно. Но у нас тут про рсубд, кого волнуют какие-то там домены/типы.
Владимир, доброго времени суток! Возможно Вам покажется, что я не прав, но все-же. Мне кажется, что в Ваших видео не хватает академичности. Например, про потенциальный ключ ничего не было сказано, да и определения послушать иногда хочется. В остальном - Вас послушать интересно.
+Виктор Пунин Согласен. Но, скажу вам честно, я просто помню, когда я сидел на уроке по базам данных и нам рассказывали про ключи, очень долго обсуждали потенциальные ключи и как стоит с ними работать, я долго потылся разобраться в этом, и в конце понял, что это что-то, что программист делает на автомате, и даже не задумывается о том, как это называется (и то, что я уже до посещения этого класса делал когда столкнулся с бд). Мне кажется, что сейчас хватает литературы, где объясняют "академически". Возьмём JOIN-ы. Я вижу что многие университеты начинают их объяснение с того, чтобы доказать математически, что данные, которые они выдают "правильны". То есть сидит человек и пытается понять разницу между INNER и OUTER, а ему приводят довод за доводом, что мол информация не теряется. Я подошёл к проблеме с другой стороны. Вот вы программист, у вас есть данные, что с ними сделать. Вот прямо сейчас. Соглашусь с вами, что для общего развития, будет хорошо, если программист попытается понять проблему более углублено. Тогда он/она поймёт почему-же мы делаем так а не иначе. И даже будет ясно почему денормализация - это полезная, но опасная вещь.
11:50 в начале лучше без чтения какой либо документации попробовать сделать самому, а потом посмотреть уроки чтоб понять как сделать было бы лучше. Так и легче воспринимать то что говорит лектор, потому что кое как уже знаешь как оно устроено в самой программе.
Как хорошо, что есть люди, которым не лень внятно и на хорошем примере провести брифинг по основным понятиям, привести хинты и разбор часто возникающих ошибок так, чтобы это было приятно смотреть.
Сам привык все узнавать из печатных источников, но данный плейлист в изобилии предоставляет всю необходимую информацию.
+Fake Potato )) Очень рад, что помогаю ))
Если бы я все узнавала по печатным источникам, то ничего бы не поняла. Спасибо тем, кто придумал Ютуб.
Иисус лучший, божественно объясняет
Покайся
Так ведь его ж Батя всё создал! Вот он и объяснил всё ему, а он нам. Элементарно же ж!
Спасибо, ты преподаешь как Боженька. По твоему видео разобрался с джоинами, хотя до этого до конца долго понять не мог. Еще раз спасибо тебе большое.
Почему - как? Обидно даже... Естественно! Ему сам Батя всё и объяснял! ☝️🥹
Спасибо вам большое за чёткое и понятное объяснение темы. Очень помогло для изучения SQL.
Большое спасибо, усваивается на 146%, словно с ложечки накормили информацией) Подписка однозначно!
Блин - чувак хочу что бы ты у нас в шараге преподавал....
Очень классно объясняешь - все понятно.... респект тебе :) так держать!
Чувак выделяется запятыми, а не тире)
@@daniilzhmak5084 ты решил что слово шарага в его предложении просто так?
@little.turok.mohamed шарага тут первичный ключ! База!
Очень толковое объяснение ключей! Спасибо )
ну как же не поставить лайк за такое простое и доступное объяснение. :-)
Вы просто лучший, о-о-очень доступно и доходчиво.
Не у всех есть талант доходчиво объяснять (учить). Спасибо! И разъяснения на доске лучше воспринимаются))
respect to you, Володька
Игумен интересно излагает!!Спасибо ему !!
Аллилуйя!
Спасибо большое! Очень интересно и доходчиво!
Более менее понял наконец-то.
Спасибо за краткое понятное объяснение.
Спасибо ! Преподаватель от Бога !
Так сын же ж! ☝️😇
желаю всем подобных преподавателей
Отличный у вас и очень информативный канал
Прикольный канал, прикольный диктор )))) Очень понятно рассказывает, молодец )))) Ждем ещё твоих выпусков ))))
Боже мой! Это видео от Бога!
Спасибо очень полезная информация,долго искал,и нашел,Спс еще раз.)
Володя, спасибо!
спасибо большое. всё предельно ясно
Владимир, доброго времени суток.
Спасибо за видео. К сожалению, в видео есть две ошибки, вернее одна ошибки и неточность.
Реляционные базы данных называются так не потому, что данные одной таблицы связаны с данными другой, а потому, что таблицы в реляционной БД являются представлением некого математического объекта отношения(Relation). Грубо говоря, отношения это сами таблицы, удовлетворяющие некоторому набору правил. А связи между таблицами лучше отношения не называть, чтобы избежать путаницы.
Неточность состоит в том, что внешний ключ это, в первую очередь, ограничение целостности данных за которым следит сама СУБД. И если, например, попытаться удалить студента у которого есть предметы, то СУБД либо не даст этого сделать либо удалит соответствующие записи в таблице Ст_Пред. Кстати есть еще одна возможность, выставить в NULL значения ячейки в зависимой таблице, что в вместе с объявлением сложного первичного ключа в таблице связей приведет к ошибке, но для данного примера выставлять в NULL бессмысленно.
Еще небольшое замечание, не стоит называть поля словом ключ, опять таки дабы избежать путаницы, лучше Ин(Идентификатор), и сказать что по этому полю создается ключ первичный (внешний) ключ, всё же ключи это слега отдельные от таблиц структуры.
Еще раз огромное спасибо за видео, оно после прочтения нудных теоретических книжек позволяет "оживить" прочитанное.
Отличное, годное уточнение к сказанному в видео.
Огромное тебе спасибо!
Мне кажется, если Володя так же будет рассказывать про существования Бога, то я смогу понять и поверить в его существования. Володя, супер!
А почему вы не верите в папу Володи? Володя то есть, значит и папа тоже.
Первичный ключ - это столбец в базе данных, где каждая строка имеет уникальное значение. Каждая таблица имеет только один первичный ключ. Значения NULL не допускаются. Уникальный ключ - это столбец или группа столбцов, которые вместе содержат уникальные значения. Таблица может иметь более одного уникального ключа. Например, в списке американских граждан столбец с номерами социального страхования будет первичным ключом, а столбцы имени и фамилии в сочетании с номером телефона - уникальным ключом.
спасибо большое за SQL лекции
Мировой мужик
Блин, Иисус, вот отлично все, но надо показать на практике все таки.
большое спасибо вам! все очень доходчиво и понятно
Офигенно объяснил!!!
Спасибо. Всё доходчиво и предельно ясно)
Офигенные лекции 👍
Спасибо за видео. Очень хотелось бы увидеть видео, где объясняются базовые понятия реляционных баз данных в вашем представлении. Судя по вашим словам в вашем понимании термин "Отношение" не совпадает с соответствующим термином в теории реляционных БД, где я как я понимаю отношение есть сама таблица с определёнными условиями.
Anatoli Zaharenko вы правы, в РСУБД отношение это набор строк и столбцов. Это может быть как таблица, так и результат выборки из несколькиъ таблиц путем объединения (union), соединения (join), произведения (cross join) и т.д.
Итак, 3 ключа: первичный, сложный и внешний !
Спасибо
Отлично. Спасибо!
Подписался и сразу лайк поставил!)
я просто перепил но не был накурен в польезде,Господи спасибо!!!
Типы ключей в базе данных 2021 )) Спасибо
Какой колоритный персонаж.. Автор наверное поклонник эпохи 70-х годов американских хиппи😁
Вы такой чистый классный объяснятель :-) а про триггеры и пример вставки с тригером?
Спасибо за видео!!!
Большое спасибо.
Спасибо, все понятно!
Я поставил 1000-й лайк! Ура, товарищи)))
Отличный урок, Володя, спасибо!
Но мне кажется, я бы не понял это, если бы у меня не было опыта в создании базы данных в Access. Я реализовывал это на практике, но не догадывался, вы же все поставили по полочкам.
все бы так объясняли..
Вот мне всё-таки интересно узнать. В книге Криса Файли "SQL" написано: "Имейте в виду, что прилагательное «реляционная» (relational), которое входит в название «реляционная база данных» (relational database), появилось благодаря математической «реляционной теории множеств» (relational set theory), а не из-за
возможности устанавливать связь (to relate) между разными таблицами по их общим значениям."
Так кому верить? Если тут и многие говорят, что "реляционная" от "устанавливать связь"? А в книге наоборот....
УУУХ, мало где есть такой стиль преподавания. Спасибо за уроки
Иисусе, ты кросавчег! Хоть я и атеист , но такой Иисус даже мне по душе ! Лайк!
Святые угодники! Не один я уверовал!
Спасибо!
п.с. 6:07 даешь ро-о-ок! =)
ещё и длинные волосы, то что надо для рока
спасибо большое, очень помогли!
Гениально.
Владимир, раскажите пожалуйста про внешний ключ.
Круто!
Божья роса подъехала, после нескольких дней боли с горедокладчиков
Благодарю
Спасибо большое)) разобрался))
Здравствуйте! Большое спасибо за видео, очень доступно и максимально понятно. Подскажите пожалуйста, какой выбрать для изучения язык программирования. В данный момент работаю уже год в QA, хочу развиваться дальше в этой отросли. Спасибо
Спасибо!
Огонь)
Можно ли что-нибудь узнать об индексации таблиц?
+Ололондий Ололоев ))) видео уже записаны. сейчас скоро буду выкладывать.
Володя привет, подскажите - я даже когда использую сложный ключ все равно в таблице делаю автоинерементное поле - как Вы считаете это верно или все же лишняя трата ресурса
+Sasha Gedz Я-бы не стал делать ещё одно поле. Когда программист видит таблицу где 2 внешних ключа формируют 1 сложный ключ, то сразу понимает в чём тут дело (связь много к многому). В том что вы делаете нет ничего плохого (количество затраченых ресурсов минимальное, не стоит волноваться если вы не вставляете что-то в эту таблицу миллионы раз в минуту), просто вы немного откланились от конвенций.
Хотя вы можете найти себя работающим в компании где (например) есть правило, что все таблицы обязательно должны содержать только 1 ключевое поле, которое автоинкриментируется. И в такой организации ваш подход как раз будет "правильным" (даже единственно правильным).
Vladimir Mozhenkov Большое спасибо за полный ответ, я как раз отношусь к людям которые долго и упорно что-то делают потом видят другой поход и начинают сомневаться в правильности всего что они делали до этого =), с каждым днем Ваш канал все интереснее и все время есть что-то новое - еще раз спасибо!
добавим год в ДР? а какого типа ДР? если это дата, то там уже есть год. не дата? нарушение 1НФ? непонятно. Но у нас тут про рсубд, кого волнуют какие-то там домены/типы.
в почти университете должна быть почти кафедра хД
Дякую!!!
Владимир, доброго времени суток!
Возможно Вам покажется, что я не прав, но все-же. Мне кажется, что в Ваших видео не хватает академичности. Например, про потенциальный ключ ничего не было сказано, да и определения послушать иногда хочется.
В остальном - Вас послушать интересно.
+Виктор Пунин Согласен. Но, скажу вам честно, я просто помню, когда я сидел на уроке по базам данных и нам рассказывали про ключи, очень долго обсуждали потенциальные ключи и как стоит с ними работать, я долго потылся разобраться в этом, и в конце понял, что это что-то, что программист делает на автомате, и даже не задумывается о том, как это называется (и то, что я уже до посещения этого класса делал когда столкнулся с бд).
Мне кажется, что сейчас хватает литературы, где объясняют "академически".
Возьмём JOIN-ы. Я вижу что многие университеты начинают их объяснение с того, чтобы доказать математически, что данные, которые они выдают "правильны". То есть сидит человек и пытается понять разницу между INNER и OUTER, а ему приводят довод за доводом, что мол информация не теряется.
Я подошёл к проблеме с другой стороны. Вот вы программист, у вас есть данные, что с ними сделать. Вот прямо сейчас.
Соглашусь с вами, что для общего развития, будет хорошо, если программист попытается понять проблему более углублено. Тогда он/она поймёт почему-же мы делаем так а не иначе. И даже будет ясно почему денормализация - это полезная, но опасная вещь.
Ещё все видео были бы связано как-то, а не просто свалены в плейлист..
Я уверовал
я тоже...
Аминь, братья и сестры!
володья, каменный век давно закончился, берешь шистый пальец, компутер, программульку записи видео с монитора, и пишешь человеческое видео
Начинаю понемногу верить в Иисуса
11:50 в начале лучше без чтения какой либо документации попробовать сделать самому, а потом посмотреть уроки чтоб понять как сделать было бы лучше. Так и легче воспринимать то что говорит лектор, потому что кое как уже знаешь как оно устроено в самой программе.
key=ID
Ему бы Head&Shoulders рекламировать, а не базам учить=)
топ
Это же Иисус спустился к нам, чтобы помочь понять БД!
А ты наблюдательный! Вносим тебя в базу данных, как наблюдательного, для дальнейшего наблюдения.
Вы верите в бога Иисуса?
Володя верит в себя! Он вообще самоуверенный и целеустремлённый человек. И знает своё дело.
неприятно смотреть на такого старца
Да, ладно! Ты же смотришь! БДСМ практикуешь? 🤨
тупейшее приветствие продоброе время суток
тупейший комментарий под видео
Спасибо!
Спасибо!