Владимир Кузнецов. Описание реляционной модели организации данных. История возникновения. Особенности реализации, сильные и слабые стороны этого подхода. SQL
Материалы полезные и доступно изложенные. Спасибо большое! Есть один минус в том что звук немного размыт и в момент когда Владимир говорит какой-то термин его трудно разобрать.
Реляционные базы, в отличие от остальных, основаны на более общей, более абстрактной , на математической идее, а потому, как частный случай, содержат и все остальные. Например вы можете запихнуть все вложенные данные одного документа в одну таблицу и у вас получится документная модель. То есть документная модель - это реляционная без реляций и с неограниченной тупой денормализацией. Те, кто не понимает внутренней красоты реляционной модели и кого тупо не натаскали на ее использование, так и используют реляционные базы - когда-то давно в 1С такое было (лет пятнадцать назад ).
Ну такое... Как реализовать, к примеру, отсутствие схемы? тот же MapReduce? Похоже, подогнав формальные признаки - безусловно. Но мы так и карьерный самосвал на развозку почты определить можем, а что, похож ведь, и колес тоже четыре :)
Для меня как для начинающего, практический ничего не понятно, кроме слов яхта, тони старк, апалон. но всё равно интересно слушать, вернусь к видео позже...
половина ролика - история. как-то много :) потом совсем коротко (минуты 3) про "данные хранятся в таблицах" (и почему тогда "релационные"? что такое отношение?), нормализацию (тут неплохо бы и про денормализацию добавить), планы (бывает, что надо как раз помочь хинтом или закрепить план), индексы (далеко не всегда. бывает и фулскан лучше). остальное - натягиваем ООМ на Реляционную Модель и почему это больно. касательно последней части - оно понятно, ибо ЦА - джаверы и иные ООПята, но в остальном - хотелось бы больше матчасти. Юмор норм :)
История - моя слабость :) Про реляционки инфы очень много, в этом ролике хотелось акцентировать внимание на то, о чем упоминают реже, чем могли бы. Касательно индексов будет отдельный ролик. И это, если ситуация с записью такова, что отсутствие индекса - лучше, чем с ним - это очень яркий индикатор того, что надо пробовать что-то на логе, а не на страницах :)
в этом и следующем видео, не знаю, как в остальных, очень сильно трясется камера и тяжело смотреть. этот футаж можно было бы исправить, если просто в какой-нибудь композерской или монтажной программе стабилизоровать изображение, сделав при этом немного крупнее его, может на 1%. у вас там сздади есть точки, за которые программа может зацепиться и даже несмотря на блюр, оттрекать и стабилизоровать изображение можно. знаю, что видео старое, но вот когда пришла, тогда и сказала.. на будущее, получается
Два одинаковых обьекта с разными инстансами это два одинаковых обьекта в БД (две строки по сути), но с разными праймари кеями. Что не понятно то? :) А так толково рассказано.
Я даже лайкнул. :):) Хорошо рассказал, но не до конца. Но оно понятно т.к. до конца рассказать, это книжка целая. ORM хорош ровно до тех пор, пока не нужно изменить модель, а по сути это про того самого верблюженка, когда мы не используем все плюшки реляционной базы, а просто используем как хранилище для обьектной ориентированного программирования. Зачастую получаем бестолковую структуру в базе с тупыми не селективными запросами. Не встречал хорошую реализацию на практике.
ну если у вас в объектной модели нет поле ключа (а зачем оно вам, вы же в программе всегда можете различить объекты по адресу), т.е. для маппинга приходится добавлять в модель дополнительное поле
Когда мы говорим о проблемах внесения изменений и миграции данных, то нужно различать два принципиально разных случая: эксклюзивный доступ к базе, когда она обслуживает запросы только разрабатываемого приложения, и случай, когда база является интеграционным слоем десятков, если не сотен систем. В случае реляционной базы мы оказываемся скорее во втором случае. Но в любом случае внесение изменений и контроль версионности (как я понимаю, Liquibase больше сосредоточена на этом) SQL модели базы на практике - это постоянная головная боль, и любая помощь тут очень welcome. Но вот в случае продакшена крупного заказчика часто все делается в ручную. Потому что тут начинают влиять многие не функциональные требования: разграничение ответственности и доступа, например. Установка новой версии ПО делается отдельными специалистами по сложным протоколам, которые были разработаны в рамках организации, и которые никто не будет менять.
Если коротко, то сейчас для инстанса реляционной базы со всеми плюшками достаточно средненького сервера, если мы хотим решать "классические" задачи. Спасибо НТП и все такое. Но аппетит приходит во время еды. Сейчас мы хотим надежность и распараллеливание выполнения тяжелых запросов на огромных массивах данных. И за смешные, по старым временам, деньги. Этого можно достичь с помощью репликации. Когда база распределена на десятках дешевеньких серверов. И тут засада: реляционные базы в репликацию умеют не очень хорошо.
Логические, или как их еще называют бизнес-ключи, конечно лучше использовать. Вот только на некоторых проектах бизнес-требования имеют тенденцию постоянно уточняться\меняться... И после третьего заваленного релиза как-то начинает свербеть мысль: эх, а вот был бы суррогатный ключик - так хоть апдейт записи нормально бы работал... :)
1. В РМ данные не хранятся а представлены, и не в виде таблиц а в виде множеств. 2. "В одной таблице хранится один тип данных" - сомнительное утверждение. Множество предваряет собой отношение, состоящее из кортежей. Каждый кортеж уникален и имеет фиксированный набор атрибутов, каждый атрибут имеет четко определенный тип данных. Понимаю что ролик обзорный и пытается охватить ещё и тему рсубд. Но всё-таки если речь про РМ то и нужно говорить в терминах РМ.
> краткость реляционной алгебры в хаотичный мир... Вот только JOIN'ы в SQL'ных базах данных нельзя объяснять на диаграммах Венна, а вот операции на множествах union/intersect - запросто. bit.ly/2ju642v Можно сказать что целая пачка книжек по SQL'ным СУБД объясняют этот момент как будто авторы pl/sql'я в жизни ни разу не касались. > реляционная модель не учитывает... полиморфизма нету... Для этого есть наследование табличек... > плохо ложиться на объектную... Все, без исключения, популярные SQL'ные базы данных умеют в JSON (даже SQLite) и представления. Жаль что не объяснили что такое Сбалансированные деревья поиска и как их дизайн лёг в основу современных СУБД, в том числе и NoSQL'ных. Откуда там взялись реляции, и почему реляции есть даже у NoSQL субд (типа MongoDB). В целом касательно реляционных баз данных бытует очень много предрассудков, но тут проблема в том что сейчас мало кто вообще понимает особенности работы и ценность для бизнеса. Для галерок выгоднее выпустить на рынок кривой продукт чтобы доить клиентов. Материал не более чем "ввод в историю", упомянутые "недостатки и преимущества" не имеют отношения к возможностям и особенностям работы современных реляционных СУБД.
@@vladymyrkuznietsov8815 на практике оно вообще вот так ruclips.net/video/wTPGW1PNy_Y/видео.html А так что на украинских галерах не то что SQL, но и просто функционал существующих СУБД не знают... уже порядком поднадоело. Жаль что у нас подобных Дилетантов продают как Синьёров/Архитектов, и это поставлено на поток.
@@YuriyYarosh Уровень снобизма на уровне мидла+, технично, но без огонька:) На практике ты используешь JSON столбец, разворачиваешь там документ резвишься там без оков схемы... Вот только почему-то при мааленьком UPDATE как-то все тормозит... Ах, вся запись переписывается, кто ж знал-то :) Но вообще, тема вариантов использования JSON действительно довольно новая и интересная, надо будет покопать...
@@vladymyrkuznietsov8815 Список мудаков-дилетантов пополнен. В JSON не умею, но снобом - обязательно обозву... жаль конечно что подобные индивиды распространяют заведомо ложную информацию ввиду собственной профессиональной несостоятельности. Желаю Вам скорого увольнения.
Я бы так не сказал. Я - почти что начинающий. Понял все, слушал с открытым ртом ))) Особенно понравилось про учебники и самую быструю яхту ) Мотивирует )
@@alexnagorny7692 зависит все от человека, мне вот не нравится читать книги технические полностью, выбираю только нужную главу и читаю, если читать сразу всю, хрен что применишь
Зачем так часто переключать камеру? Там, что маньяк оператор сидит что-ли? Издевательство какое-то, испытание нервов зрителя. И звук тоже слабоват. И не "указИвает" (10:12), а указЫвает. Лучше Сергея слушать, ей Богу...
@@vladymyrkuznietsov8815 Аа... Так это вы тот самый оператор ?! :) Раз на вас подействовало мое замечание. :) Я постоянный слушатель данного канала и мне интересно слушать именно Сергея. Извините. Но я даже когда пишу комментарий, по десять раз проверяю есть ли в нем грамматические ошибки. Не говоря уже о подготовке видео к всеобщему обозрению. А если бы записывал видео, то сначала протестировал, слышно ли вообще говорящего в нем или нет.
@@SergeyNemchinskiy При всем моем уважении, Сергей. Я всегда жду с нетерпением хотя бы "загоны". Но именно от вас. Ех... Жаль, что лекций давно уже нету...
"правило 3 секунд" при мантаже видео, если не замечали, то держать картинку более 10 секунд плохая идея .. единственное что тут не так, это один и тот же человек в кадре, переключиться не на что ) можно котиков добавить
BeforyDeath , слыхали правило 3 секунд. Можно несколько камер поставить с разными ракурсами. Можно к видео десяток слайдов подготовить и переключаться на них время от времени. Но в любом случае, всем спасибо за видео. Очень интересно. Ждём продолжения.
ORM это тупиковый путь, который только усиливает проблемму взаимодействия с ООП языком и убивает оптимизации и кучи фичь. Даже простой для БД и повсеместный join это целая боль.
лсд тогда продавалась на улицах, проблем с идеями ни у кого не было ))))
Те кто жевал лсд в книги не попали и уж тем более на язтьі!
Спасибо, что приглашаете профессионалов. Приятно и интересно послушать :)
громкость бы добавить и музыку убрать а то плохо слышно
нормально слышно
У автора просто талант при хорошем звуке бубнить неразборчиво
Владимир, обожаю ваши видео. Всегда чётко и по делу, но при этом с аккуратными шуточками (про лсд, про почти всегда). Спасибо большое.
😂 Что значит почти всегда? Это значит у всех всегда, а у Вас почти. 👍 Пережито.
что значит "почти всегда"? это значит, что у всех всегда, а конкретно у вас - почти.
в фонд золотых цитат.
Владимир, спасибо отличный материал!
Сергей Н. благодарствуем! Про лсд и идеи 💡- это мощно 🤣
Весь ролик пытался для себя решить, на кого он больше похож, на худого линуса торвальда или на толстого максима галкина.
Вот оно, единство формы и содержания! :)
На волосатого Антона Логвинова
Токсичный коммент
Спасибо большое за это видео! Удивительное сочетание, когда приятно слушать и полезно и интересно.
Не говорит , а мурчит) очень приятное изложение
Материалы полезные и доступно изложенные. Спасибо большое!
Есть один минус в том что звук немного размыт и в момент когда Владимир говорит какой-то термин его трудно разобрать.
Спасибо большое. Очень интересно рассказываете! Приятно слушать.
Отличное видео. Дякую
”Что значит почти всегда?..”😂😂😂
Отличное видео. Очень интересное.
Все хорошо, но музыка мешает - громко слишком.
Ждем модель на основе графов)
Тайминги, очень нужны.
Реляционные базы, в отличие от остальных, основаны на более общей, более абстрактной , на математической идее, а потому, как частный случай, содержат и все остальные. Например вы можете запихнуть все вложенные данные одного документа в одну таблицу и у вас получится документная модель. То есть документная модель - это реляционная без реляций и с неограниченной тупой денормализацией. Те, кто не понимает внутренней красоты реляционной модели и кого тупо не натаскали на ее использование, так и используют реляционные базы - когда-то давно в 1С такое было (лет пятнадцать назад ).
Ну такое... Как реализовать, к примеру, отсутствие схемы? тот же MapReduce? Похоже, подогнав формальные признаки - безусловно. Но мы так и карьерный самосвал на развозку почты определить можем, а что, похож ведь, и колес тоже четыре :)
Для меня как для начинающего, практический ничего не понятно, кроме слов яхта, тони старк, апалон. но всё равно интересно слушать, вернусь к видео позже...
Офигенный чел
Майка огонь! )
Зачем камера скачет?
Меня сейчас стошнит!
Писал на яхте :) Оператор сказал, что сейчас так модно.... Но да, меня тоже укачало, попробовали - и хватит...
пока не прочитал этот коммент, не замечал. потом тоже качать начало🤣
Фишки блогера
не смотри в чем проблема? лол какой-то
половина ролика - история. как-то много :) потом совсем коротко (минуты 3) про "данные хранятся в таблицах" (и почему тогда "релационные"? что такое отношение?), нормализацию (тут неплохо бы и про денормализацию добавить), планы (бывает, что надо как раз помочь хинтом или закрепить план), индексы (далеко не всегда. бывает и фулскан лучше). остальное - натягиваем ООМ на Реляционную Модель и почему это больно. касательно последней части - оно понятно, ибо ЦА - джаверы и иные ООПята, но в остальном - хотелось бы больше матчасти. Юмор норм :)
История - моя слабость :) Про реляционки инфы очень много, в этом ролике хотелось акцентировать внимание на то, о чем упоминают реже, чем могли бы. Касательно индексов будет отдельный ролик. И это, если ситуация с записью такова, что отсутствие индекса - лучше, чем с ним - это очень яркий индикатор того, что надо пробовать что-то на логе, а не на страницах :)
Сергей,можете сделать видео,про то какие задачи встречаются на реальных проэктах? Спасибо.
Владимир судя по всему не прочь вернуться к старой практике генерации идей)
Молодец!
Супер, исЧё!
Это Немчинский музыкальный аккомпанемент играет?
в этом и следующем видео, не знаю, как в остальных, очень сильно трясется камера и тяжело смотреть. этот футаж можно было бы исправить, если просто в какой-нибудь композерской или монтажной программе стабилизоровать изображение, сделав при этом немного крупнее его, может на 1%. у вас там сздади есть точки, за которые программа может зацепиться и даже несмотря на блюр, оттрекать и стабилизоровать изображение можно. знаю, что видео старое, но вот когда пришла, тогда и сказала.. на будущее, получается
👌👏
Суть только с 9:30 начинается
Автор с головой дружит!
Два одинаковых обьекта с разными инстансами это два одинаковых обьекта в БД (две строки по сути), но с разными праймари кеями. Что не понятно то? :) А так толково рассказано.
Я даже лайкнул. :):) Хорошо рассказал, но не до конца. Но оно понятно т.к. до конца рассказать, это книжка целая. ORM хорош ровно до тех пор, пока не нужно изменить модель, а по сути это про того самого верблюженка, когда мы не используем все плюшки реляционной базы, а просто используем как хранилище для обьектной ориентированного программирования. Зачастую получаем бестолковую структуру в базе с тупыми не селективными запросами. Не встречал хорошую реализацию на практике.
ну если у вас в объектной модели нет поле ключа (а зачем оно вам, вы же в программе всегда можете различить объекты по адресу), т.е. для маппинга приходится добавлять в модель дополнительное поле
👍
Спасибо
Что меня развивае - то должно получить лайк
Привет! На счет миграции: насколько я знаю, эту проблему могут решать штуки типа Liquibase и FlyWay. Что думаете о них?
Когда мы говорим о проблемах внесения изменений и миграции данных, то нужно различать два принципиально разных случая: эксклюзивный доступ к базе, когда она обслуживает запросы только разрабатываемого приложения, и случай, когда база является интеграционным слоем десятков, если не сотен систем. В случае реляционной базы мы оказываемся скорее во втором случае. Но в любом случае внесение изменений и контроль версионности (как я понимаю, Liquibase больше сосредоточена на этом) SQL модели базы на практике - это постоянная головная боль, и любая помощь тут очень welcome. Но вот в случае продакшена крупного заказчика часто все делается в ручную. Потому что тут начинают влиять многие не функциональные требования: разграничение ответственности и доступа, например. Установка новой версии ПО делается отдельными специалистами по сложным протоколам, которые были разработаны в рамках организации, и которые никто не будет менять.
@@vladymyrkuznietsov8815 понятно, спасибо
@@vladymyrkuznietsov8815 Как же ж это круто звучит. Поверим на слово :) вот бы поработать под твоим началом и это всё прочувствовать на деле!
каждый раз вздрагивал при появлении надписей из-за звука покупки итема у игрока из линяги
раскройте пожалуйста шире причину явления 9:32 - 9:40
Если коротко, то сейчас для инстанса реляционной базы со всеми плюшками достаточно средненького сервера, если мы хотим решать "классические" задачи. Спасибо НТП и все такое. Но аппетит приходит во время еды. Сейчас мы хотим надежность и распараллеливание выполнения тяжелых запросов на огромных массивах данных. И за смешные, по старым временам, деньги. Этого можно достичь с помощью репликации. Когда база распределена на десятках дешевеньких серверов. И тут засада: реляционные базы в репликацию умеют не очень хорошо.
Пожалуйста: что почитать + пару вопросов на собеседование (сейчас java-dev: june).
june это июнь?
@@darkcrusaderzxc июньский урожай))))
1с8 - объектная + реляционная
Почему суррогатные ключи лучше использовать чем логические, кроме абстрагирования ключа от реальных данных...
Логические, или как их еще называют бизнес-ключи, конечно лучше использовать. Вот только на некоторых проектах бизнес-требования имеют тенденцию постоянно уточняться\меняться... И после третьего заваленного релиза как-то начинает свербеть мысль: эх, а вот был бы суррогатный ключик - так хоть апдейт записи нормально бы работал... :)
ты похож на линуса торвальдса😁
Линус когда не знает - ерунды не говорит...
Больше морковки и капусты ешьте
Музыка перебивает речь. Вообще можно было без музыки оставить видео.
offtop, но гитарка на фоне клевая
mikola.o.net/ не работает, я проверял
1. В РМ данные не хранятся а представлены, и не в виде таблиц а в виде множеств.
2. "В одной таблице хранится один тип данных" - сомнительное утверждение. Множество предваряет собой отношение, состоящее из кортежей. Каждый кортеж уникален и имеет фиксированный набор атрибутов, каждый атрибут имеет четко определенный тип данных.
Понимаю что ролик обзорный и пытается охватить ещё и тему рсубд. Но всё-таки если речь про РМ то и нужно говорить в терминах РМ.
привет ,кому скинули видосик на паре)(информатика)
10:17 очепятка на ошибке
> краткость реляционной алгебры в хаотичный мир...
Вот только JOIN'ы в SQL'ных базах данных нельзя объяснять на диаграммах Венна, а вот операции на множествах union/intersect - запросто.
bit.ly/2ju642v
Можно сказать что целая пачка книжек по SQL'ным СУБД объясняют этот момент как будто авторы pl/sql'я в жизни ни разу не касались.
> реляционная модель не учитывает... полиморфизма нету...
Для этого есть наследование табличек...
> плохо ложиться на объектную...
Все, без исключения, популярные SQL'ные базы данных умеют в JSON (даже SQLite) и представления.
Жаль что не объяснили что такое Сбалансированные деревья поиска и как их дизайн лёг в основу современных СУБД, в том числе и NoSQL'ных. Откуда там взялись реляции, и почему реляции есть даже у NoSQL субд (типа MongoDB).
В целом касательно реляционных баз данных бытует очень много предрассудков, но тут проблема в том что сейчас мало кто вообще понимает особенности работы и ценность для бизнеса. Для галерок выгоднее выпустить на рынок кривой продукт чтобы доить клиентов.
Материал не более чем "ввод в историю", упомянутые "недостатки и преимущества" не имеют отношения к возможностям и особенностям работы современных реляционных СУБД.
Без комментариев, главное, не держите это в себе, почаще говорите это на собеседованиях, несите правду, так сказать, в свет! ;)
@@vladymyrkuznietsov8815 на практике оно вообще вот так ruclips.net/video/wTPGW1PNy_Y/видео.html
А так что на украинских галерах не то что SQL, но и просто функционал существующих СУБД не знают... уже порядком поднадоело.
Жаль что у нас подобных Дилетантов продают как Синьёров/Архитектов, и это поставлено на поток.
@@YuriyYarosh Уровень снобизма на уровне мидла+, технично, но без огонька:) На практике ты используешь JSON столбец, разворачиваешь там документ резвишься там без оков схемы... Вот только почему-то при мааленьком UPDATE как-то все тормозит... Ах, вся запись переписывается, кто ж знал-то :) Но вообще, тема вариантов использования JSON действительно довольно новая и интересная, надо будет покопать...
@@vladymyrkuznietsov8815 Список мудаков-дилетантов пополнен. В JSON не умею, но снобом - обязательно обозву... жаль конечно что подобные индивиды распространяют заведомо ложную информацию ввиду собственной профессиональной несостоятельности.
Желаю Вам скорого увольнения.
@@YuriyYarosh "Педро, ты разбил мое сердце" (с) ;)
Что с камерой? Трясется.
Autofocus maybe.
так сейчас модно, говорили они, будет оживлять, говорили они... :)
Кабана чувак прочитал
сколько воды...
человек заходит смотреть видео с целью разобраться в самих базах, а не получить урок истории
Вода до 10й минуты
можно погромче!!!!
Если это видео для начинающих, так они не усвоят и половины, потому что не та подача материала... А опытные разрабы и так знают этот материал.
Мидлл сайз. Аккурат для нерадивых асушников
Я бы так не сказал. Я - почти что начинающий. Понял все, слушал с открытым ртом ))) Особенно понравилось про учебники и самую быструю яхту ) Мотивирует )
@@alexnagorny7692
зависит все от человека, мне вот не нравится читать книги технические полностью, выбираю только нужную главу и читаю, если читать сразу всю, хрен что применишь
Зачем так часто переключать камеру? Там, что маньяк оператор сидит что-ли? Издевательство какое-то, испытание нервов зрителя. И звук тоже слабоват.
И не "указИвает" (10:12), а указЫвает.
Лучше Сергея слушать, ей Богу...
Алексей, до сих пор вы нашли только одну опечатку, это издевательство какое-то, лучше бы другие зрители камментили, ей богу... ;)
@@vladymyrkuznietsov8815 Аа... Так это вы тот самый оператор ?! :) Раз на вас подействовало мое замечание. :) Я постоянный слушатель данного канала и мне интересно слушать именно Сергея.
Извините. Но я даже когда пишу комментарий, по десять раз проверяю есть ли в нем грамматические ошибки. Не говоря уже о подготовке видео к всеобщему обозрению. А если бы записывал видео, то сначала протестировал, слышно ли вообще говорящего в нем или нет.
@@SergeyNemchinskiy При всем моем уважении, Сергей. Я всегда жду с нетерпением хотя бы "загоны". Но именно от вас. Ех... Жаль, что лекций давно уже нету...
"правило 3 секунд" при мантаже видео, если не замечали, то держать картинку более 10 секунд плохая идея .. единственное что тут не так, это один и тот же человек в кадре, переключиться не на что ) можно котиков добавить
BeforyDeath , слыхали правило 3 секунд. Можно несколько камер поставить с разными ракурсами. Можно к видео десяток слайдов подготовить и переключаться на них время от времени.
Но в любом случае, всем спасибо за видео. Очень интересно. Ждём продолжения.
tegomotina
ORM это тупиковый путь, который только усиливает проблемму взаимодействия с ООП языком и убивает оптимизации и кучи фичь. Даже простой для БД и повсеместный join это целая боль.
1st)
Реляційні бази і зараз для банків безальтернативні. ОРМ - фігня повна - не користуйтесь
Согласен: орм - похоже на фигню
Базогуру! щеб українською мовою ціни б вам не було!