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