11 - Внешние ключи (Foreign Keys) - Уроки PostgreSQL
Вставка
- Опубліковано 18 жов 2024
- Войти в IT: Вся Необходимая База. 3 Уровня Объяснения Материала
stepik.org/a/1... Если не можешь напрямую покупать со Stepik, заказывай отсюда:
avecoders.gith... Введение в Искусственный Интеллект с Python для Начинающих: stepik.org/a/1... Введение в Искусственный Интеллект с Python для Начинающих: stepik.org/a/1... Курс: "Поколение Трансформеров": Нейросети для Естественного Языка (NLP)
Вне Свифта (Россия, Беларусь): stepik.org/a/1...
Свифт (Все остальные): avecademy.teac...
Практический Курс по Python:
Stepik: stepik.org/a/1...
Udemy: www.udemy.com/...
Аве Кодер! В этом уроке мы на практике разберем пользу от первичных ключей. В качестве примера мы возьмем бонусную схему вымышленного работодателя по которому, наши работники должны получить в качестве бонуса велосипед.
Но не все так очевидно - наше решение в Postgresql должно отвечать трем обязательным условиям:
1) Работник может получить только один велосипед
2) Велосипед может принадлежать только одному работнику
3) Это может быть либо велосипед, либо ничего.
В этом нам как раз и помогут внешние ключи.
Следующее видео:
12 - Объединение таблиц (JOINS) - Уроки PostgreSQL
• 12 - Объединение табли...
Предыдущее видео:
10 - UPSERT и Работа с Конфликтами (ON CONFLICT DO) - Уроки PostgreSQL
• 10 - UPSERT и Работа ...
Плейлист целиком:
• Уроки PostgreSQL для н...
#авекодер #урокиpostgresql #postgresql #sql #субд
Поддержи проект:
www.donational...
paypal.me/avecoder
/ avecoder
BTC: 1BmLvUFiJaVpCAwhzW3ZwKzMGWoQRfxsn4
ETH: 0x6f1A488c9b12E782AEF74634a40A79b1631237aB
История Технологий:
/ АвеТех
VK: avecoder
Телега: t.me/avecoder_ru
______________________
Аве Кодер! Меня зовут V и я кодер. На моем канале ты сможешь найти актуальные туториалы по интересным технологиям, базу по computer science, брейнхаки, лайфхаки, материалы по здоровью кодера, отчеты о визитах в интересные локации, английский для кодера, как кодеру не помереть с голоду, юмор и многое другое.
Так что ставь императорский палец вверх, подписывайся и бей в колокол!
Практический Курс по Python:
Stepik: stepik.org/a/126242
Udemy: www.udemy.com/course/avecoder-advanced-python/?referralCode=270C5D0661A966B53743
Очень классно объяснил, спасибо большое) 👍
Всем друзьям советую кто учит со мной
Уроки огонь! Как фильмы со Стэтэмом! Этот комментарий будет историческим, ибо 3,24 тыс. подписчиков ты не достоин. Нужно как минимум пол ляма.
Спасибо
Спасибо! Очень доходчиво рассказываете!
отличные уроки, спасибо!
не сработало так, но разобрался с этим инженерингом мтодом проб и ошибок. Почувствовал отличие от mySQL основательное))
Спасибо за старания)
Подскажите плиз почему до этого мы делали уникальным поля через команду : ADD CONSTRAINT unique_email UNIQUE (email)
А сейчас просто через ADD UNIQUE (bicycle_id) есть определенные условия для этого или есть какая то разница?
Отвечаю на комментарий годовой давности, раз никто не ответил. Одно дело изменять уже существующее поле, делая его уникальным (email), а другое, добавлять новое уникальное поле (bicycle_id)
Добрый день. А как потом вывести данные по второй таблице используя первую. То есть как сделать select, чтобы с данными первой таблицы и вывелся столбец, что именно этот велик принадлежит Лизе.
Спасибо!
Отличные уроки, спасибо! Но у меня есть вопрос: почему вы используете '100.00', а не просто 100.00? Price же чисельной тип.
чтобы показать, что PostgreSQL может спарсить String в numeric даже с ' '. Это одна из пасхалок которые я раскидал по курсу. Молодец!
4:40 А почему bicycle_id в таблице велосипедов у нас bigserial, а в таблице *emplpoyee* bigint?
Непонятно с уникальным полем nullable, перед присвоением bycicle_id все значения были одинаковыми. Мне кажется что с таким индексом пустой может остаться лишь одна запись.
простите ради бога, не могу удержаться........
БИКУКЛЕ
Т. е. в результате получится что только один работник (с одним id) может иметь к примеру велосипед Indi ATB, а другой работник этот же велосипед иметь не сможет? Или всё-таки сможет?
Привет. Я настоятельно рекомендую экспериментальным путем проверять гипотезы. Напиши потом сюда, к какому выводу ты пришел.
@@avecoder Экспериментальный путь проверки гипотезы показал, что всё-таки один работник может иметь только один велосипед из таблицы bicycle ☝️. Спасибо, я просто как велолюбитель сам себя запутал в процессе урока.
@@avecoder , здравствуйте! Есть вопрос: если я уже создал поле bicycle_id предварительно командой ALTER TABLE employee ADD bicycle_id BIGINT; а потом хочу создать связь foreign key c id таблицы bicycle. Но я уже не могу выполнить команду ALTER TABLE employee ADD bycicle_id BIGINT REFERENCES bicycle (id); , потому что bicycle_id уже создан. Что делать в таком случае, если удалять поле bicycle_id не хочется?
Познавательное видео и ни одного комментария?
Безумно можно быть первым
Я вот верстаю ролики по сто раз и такой вопрос навернулся: а можно уже существующее поле преобразовать во внешний ключ? Просто не совсем представляю, как оно должно выглядеть, и просто хотелось бы сохранить порядок столбцов. Но если такое провернуть нельзя, то тоже хотелось бы знать.
можно. об этом и урок
@@avecoder я не увидела этого, тут только создается новое поле с внешним ключом, а на уже созданное не было. Хотя может я действительно слепа, пересмотрю, возможно, видео.
@@gottastoppo Что выдает гугл по запросу о проблеме?
@@avecoder Не поняла немного.
Ничего пока путного не находила, но займусь этим вопросом поглубже уже позже.
@@avecoder Хорошо, я вот такую информацию нашла: postgrespro.ru/docs/postgrespro/9.5/ddl-constraints
Не знаю, подходит ли оно сюда, но если да, то такого у вас в видео точно не было.
РЕД: не совсем то, что нужно, но хоть что-то близкое.
как сделать так чтобы bicycle_id (которых 3 ) могли относиться ко всем сотрудникам?
Прикольно, но не понятно нафига оно нужно и что даёт.
и действительно нафига нужен SQL
@@avecoder возможно вопрос был "зачем вообще нужны foreigh key?" у меня такой же вопрос, я именно из-за него сюда зашел. Делаю приложение простое, там три таблицы. Но не могу заполнить child, пока не заполню родительскую, а мне это не удобно с точки зрения асинхронности приложения - у меня разные методы пишут в разные таблицы, и я не знаю какой выполнится раньше. Хотел найти ответ на вопрос "можно ли без внешних ключей". А что не будет работать? Выборка? Джоины? Мне кажется, должны работать же?
@@Office-Clerk да, технически невозбраняется зафигачить все в одну таблицу, как здесь: ua-cam.com/video/SnBhRJVXkJw/v-deo.html что можно сравнить с написанием программы в одном файле. Многие ребята могут несколько лет проработать в IT, так и не использовав ни один Foreign Key (softwareengineering.stackexchange.com/questions/375704/why-should-i-use-foreign-keys-in-database), но как и со всем прочим, разделяя свою БД логически, ты облегчаешь себе жизнь в дальнейшем. Пример из видео: мы раздаем работникам велосипеды, но представь, что мы решили раздавать машины, но возможно вернемся к велосипедам позже (летом). Гораздо проще по внешнему ключу подключить таблицу с машинами, нежели вбивать в основную таблицу доп. поля, которые может будут использоваться, а может нет. Внешний ключ работает как реферальная ссылка из одной таблицы к другой. Но опять же, если у тебя простое приложение, которое обращается к каждой таблице отдельным запросом, то проблем пока что не возникнет.
@@Office-Clerk Это дает огромное преимущество. Представьте вы пишете код допустим на php. И вам нужно удалить работника, но за работником стоят куча таблиц отдельных где есть ссылки на данного работника. В обычном варианте вам предается реализовать удаление всех таблиц, а именно каждую в ручную. А так вы можете настроить что БД сама позаботится об удалении всех связанных записей и для этого в том числе понадобится внешний ключи.
Спасибо!