PostgreSQL: как связь 1 к 1 ускоряет базу данных? Разбираемся во внутренней работе СУБД

[@t0digital]

Тем временем мой курс «Хардкорная веб-разработка» продолжается - course.to.digital

[@MadoxXx]

Видно, что человек много сил вложил в видео, спасибо за материал.

[@t0digital]

Спасибо!

[@NN-jx8kb]

Вот уже как два года смотрю ваши видео. Спасибо вам за ваш труд, очень приятно смотреть на то, как развивается канал и качество видео! Успехов!

[@sher1x165]

Леша, здоровья тебе! Контент дико полезный

[@t0digital]

Спасибооо!

[@Олександр-ю9н]

Спасибо за видео! Пожалуйста продолжайте по PostgreSQL

[@dovakin541]

Алексей, большое человеческое Спасибо за ролики про БД. Помогает взбодриться и увидеть слабые места в своих знаниях (я аналитик)

[@captainkryuk1899]

Как обычно шикарное видео! Было приятно увидеться в мандарине)

[@ViacheslavKonn]

До вашего ролика терпеть не мог работать с бд😂. Теперь вижу, что в ней полно интересных вещей и нюансов. Наверное, неприязнь и связана с незнанием предемета Спасибо за ролик

[@maksimmuruev423]

Неприязнь работы с бд связанная с двумя вещами с SQL синтаксисом, и с утвержденим (ложным) - вам не надо знать как это работает просто пишите sql... Если бы предмет БД вели так как здесь расскзаывая что внутри ошибок было бы меньше и странных решений.

[@onermaster]

Респектую вашей дотошности)

[@bistronousogust]

Всё предельно понятно, шеф. Спасибо.

[@shtimn]

Крутое познавательное видео, особенно понравилось информация о том как хранятся таблицы на диске Ждал половину ролика когда же уже будет про TOAST, на примере что же будет если одна запись будет больше одной странички в 8КБ, но не было. Буду ждать в следующих роликах

[@Be3y4uuK0T]

это видео супер познавательное и такое крутое открытие, теперь буду знать и использовать! спасибо огромное!!

[@SetMafia]

Круто стал снимать с двух камер. Респект

[@andreigolovaciuc9855]

Спасибо за супер полезный контент, одно замечание по монтажу ролика, попал отрезок видео без обработки по цветам 21:18 - 21:36. 🙃

[@Владимир-ц3л5ц]

Круто, много интересной информации о том как работает Postgres

[@t0digital]

Спасибооо!

[@Ura2404]

Спасибо, доступно и очень полезно.

[@MichioSempai]

В postgres есть наследование таблиц, кажется что это именно тоже самое вы сейчас реализовали руками. Таким образом если нужно много данных, то обращаемся к дочерней таблице, а если мало то только к той которая содержит нужную нам информацию.

[@kutuzov13]

Алексей, спасибо за видео! Жду продолжения по БД-шкам :) Было интересно посмотреть твой разбор

[@t0digital]

Спасибооо!

[@sariya271]

С таким светом все очень похоже на сцены с Рассказчиком из игр The Dark Pictures Anthology 😄

[@thelookin8237]

Спасибо за видео! Выписал себе пару идей для проектов.

[@ИванКулеш-х9и]

Большое спасибо за видео. Теперь будет, что переслать тем, кто говорит что 1-к-1 - это одна таблица.

[@ExModE74]

Спасибо! А почему индекс-то не по дате?)

[@dmitryivanov5940]

Очень полезный контент, автору однозначно респект. Однако, граждане, без фанатизма - а то крайний случай такого подхода это каждому атрибуту сущности по таблице (например, бывает что О из ФИО нет, то есть, возможны null’ы и бац - ФИО разлетается по разным таблицам). Истина, как обычно, где-то посередине 😊

[@TheDelwish]

истина она в том как будет юзаться бд и какие запросы под нее будут писаться. никто в здравом уме не будет делать двойной джоин чтобы сделать ФИО. поэтому пример вообще не в тему. по этой причине важно моделирование данных , до того как будет проектироваться бд. где нужно расписать основные юз-кейсы, что и как будет делаться. из чего легко понять плюс минус какие таблицы и как нужно делать. зло это over-engineering и попытка решать какие-то проблемы, которых даже в планах не факт что будет. из-за чего даже неглупые люди я видел плодили каких-то монстров на 40 таблиц, когда все решалось в 4 таблицы. и дело вовсе не 1-many, many-many, 1-1 связях. а в том что решались проблемы масштаба гугла, которых у конторы вообще никогда и не будет.

[@nage7447]

19:40 а если по партишенам разбить? департамент вполне подходит как колонка на эту цель )

[@Alextele2]

Огромное спасибо за видео! Просто отличная база для начинающих дата инженеров! А возможно сделать то же самое для Clickhouse либо другую колончатую БД?

[@t0digital]

пока что у меня мало опыта с колоночными:)

[@fotopetroler]

в книге Томаса Кайта это все хорошо описано. Да Кайт писал про Oracle, но принципы работы с B-tree индексом она в общем то одинаковая, там упоминается некоторое правило, как сейчас помню, что если необходимо выбрать до 3-5% записей таблицы, то индекс поможет, если же нужно вернуть больше, то будет Full scan, он же seq scan в PostgreSQL. И с физической точки зрения это оправдоно. т.к. индекс - это отдельная структура данных B-tree(очевидно). которая хранит обычно до 2-3 уровней, и в своих листовых блоках(страницах) хранит ссылки на конкретные строки в оракле это (row id) в PostgreSQL не помню. Так вот если начать читать все из индекса, там искать rowid по нему ходить в таблицу вычитывать данные, и так по всем строкам, то это будет жутко не эффективно. т.к. придется прочитать 2 структуры данных - сам индекс, и саму таблицу. Собственно по этому CBO (Cost Base Optimizator) и принимает решение не читать 2 структуры, а сразу читать все таблицу. )

[@user-a9vhqazbm1]

Очень качественно!

[@Andron4iKTV]

Посмотрел первые 4 минуты но могу сразу сказать. Первое что пришло в мысли это оферфетч пейджов в пострге. Если разделять таблицы и делать связь 1к1 то можно уменшить I/O для некоторого спектра запросов но так же и увеличить для других. Тут трейдофф. Везде трейдоффы есть. Второе лучшая компрессия если типы данных схожи.

[@maksimkuznetsov2132]

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

[@den-rad]

Спасибо за видео!

[@Murderface000]

Добрый день! Подскажите пожалуйста, как измениться план запроса, если в запросе соединить все таблицы из базы norm_tables через inner join?

[@alexanderegorov6115]

Во многом согласен. Но, возможно, стоило бы добавить еще следующее: - В действительно сложных запросах, которые будут использовать много таблиц и большую часть из таблиц, полученных при разбивке на связи 1 к 1, уменьшается шанс, что оптимизатор с лету построит самый оптимальный план, потому что увеличение количества джоинов может привезти в взрывному количеству возможных планов запроса. Тут опять же все может зависеть от конкретной схемы данных и самих данных - увеличение количества таблиц может привести к увеличению смысловой нагрузки человеком, как при анализе схемы данных, так и при чтении запроса. Как крайний случай, можно упомянуть якорную модель данных для хранилищ данных, которая тоже имеет свои плюсы, но простота восприятия километровых запросов к ним не относится - если таблица широкая, но сильно разряженная с большим количеством не длинных колонок переменной длины, то думаю, что все будет не так показательно, многое будет зависеть от средней длины строки - по тому как устроена БД думаю, что полезно бы было сказать про то, что будет, если строка не будет влезать в один блок/страницу из-за большого количества колонок - про селективность важное уточнение: нет четкого определения для любого случая о хорошей селективности, все зависит от того сколько будет накладных расходов при использовании индекса (можно ли получить всю информацию необходимую для запроса из индекса или нет, сколько блоков таблицы нужно считать после скана индекса и т.д.) по сравнению с последовательным сканом таблицы. И это только если говорить о дефолтных btree индексах.

[@youtubespectator]

Алексей, расскажите, пожалуйста, откуда вы черпали самые ценные практики для работы: книги, курсы, статьи, видеолекции?

[@t0digital]

На первое место поставил бы книги

[@ildar7sins]

Хороший видос, правда я никогда не слышал что бы кто то плохо говорил о связи 1к1, кажется наоборот, все учились по нормальным формам и дальше не углублялись, видимо только автор книги про тесты так считает)))

[@evgenym574]

Алексей, привет. Спасибо за материал. По-моему был у вас видос про нормальные формы в БД. Так вот эта широкая таблица нарушает 1НФ прям двумя ногами) Так что, кажется, что ваши выводы очевидны, тут вы на практике их доказали просто)

[@ivannetch4255]

Нарушение 1НФ было бы, если бы в одно поле запихали бы, например, имя и номер телефона через пробел. Или, по-факту, хранение имени и фамилии через пробел в одном поле - это тоже нарушение 1НФ

[@Валентин-Бируля]

Подскажи, пожалуйста. Жив ли еще книжный клуб? А то информация не обновлялась с июля

[@t0digital]

Мы сейчас дочитываем Создание микросервисов Ньюмена и затем читаем Kafka в действии. График сдвинулся. Как закончим будем выбирать следующую

[@vadim-kv]

Досмотрел видео до выборки. Вы делаете выбор по основной таблице. Добавьте условия по FK и результат будет другой. Потом опять же есть json тип поля.

[@t0digital]

Речь о сценариях использования. Если есть сценарии использования, в которых не нужны данные доп таблиц, то по ним не то что фильтрации нет, их вообще в запросе нет.

[@mrfriz]

Очень интересно! В MySQL такая же ситуация?

[@olapsema]

Мне кажется он скорее не стал брать индекс из-за order by, а не из-за селективности, т.к. какой ему смысл брать индекс, если ему придется все равно ходить в таблицу, чтобы получить значение колонки с датой, чтобы потом сложить в темп таблицу и отсортировать эту историю Попробовать бы индекс с датой + айди департамента

[@olapsema]

Плюс можно попробовать делать запрос в 2 этапа, в тяжелом выбирать только айди, а потом по айдишникам выбирать отдельно нужные колонки, не знаю как с постгрессом, но мускулом лишний повод не лезть в таблицу часто помогает ему понять, что лучше использовать индекс, а не игнорировать его

[@_iPilot]

К тому же с небольшими таблицами при использовании подхода CodeFirst куда приятнее получает иерархия классов, которые меньше сами по себе.

[@TheDoktorzet]

20:52 Там разница между 0,102 ms и 1,212 ms в 12 раз, как мне показалось... А не "почти так же". Но ролик бомба, как обычно 👍 Спасибо!

[@t0digital]

это всё в рамках погрешности, когда и результаты, и разница в рамках одной миллисекунды.Когда разница сотни миллисекунд и больше - это существенно, а одна миллисекунда это не закономерность. На разных запусках то, что было 0.1 мс может стать 3мс, а то, что было 1.2мс может стать 0.1мс.

[@MsByArt]

Добрый день. Интересное видео, спасибо. А как вы относитесь к хранению в jsnonb, для связи один к одному? Какие недостатки/преимущества?

[@t0digital]

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

[@dimachen86]

Алексей, а как насчет json field колонки, как альтернатива one to one? Современные базы данных довольно хорошо уже работают с json полями. В запросах select можно просто не указывать json колонку на выборку, когда это не нужно.

[@MichioSempai]

Если вы хотите в PG использовать json как *резиновую" Таблицу, то вас скорей нужен не json а hstore, места жрёт в 2 раза меньше а скорость такая же. При использовании такого рода рода данных вы теряете главный + реляционных субд: типизацию и констрейны и теперь всё придётся реализовывать на уровне приложения или писать хранимки.

[@dimachen86]

@@MichioSempai hstore - может подойти в определенных ситуациях вместо json, когда значения не представляют собой сложную иерархическую структуру данных. Когда нужно хранить только ключ - значение. На малых объемах данных когда нет большой нужды озадачиваться производительностью Json более универсальный тип данных. Да, теряется типизация, но зато приобретается гибкость хранения данных. Типизацию можно организовать на уровне приложения. JSON бывает очень удобен когда очень часто изменяется схема базы данных. Например, когда разрабатываем сложную анкету с данными о пользователе и заказчик раз 5 в день изменяет структуру полей, которые должны быть в этой анкете и эти поля могут иметь сложную вложенную структуру данных. Например, Специальность у специальности есть Город и сущность Специальность может иметь более одного значения.

[@MichioSempai]

@@dimachen86 Если у вас такое приложение, где из-за любого веления пятки необходимо проводить миграцию, то возможно ваша схема базы данных изначально была выбрана не правильна. К использования таких сложных типов как Json нужно подходить очень осознанно. Пока единственным более менее аргументированным сценариям который я видел это хранение журналов событий, где каждое событие имело сложную развесистую структуру. И то напрямую с данными из json мало кто работал, в основном все использовали отдельные вьюхи под конкретные задачи. Гибкость хранения данных это не плюс, а как раз минус. Теперь вам нужно думать что будет, если там окажутся данные не того типа, проверять ключи вручную. Не спорю json дает гибкость, в простых приложениях ей можно заменить, например, EAV модель хранения. Но кода при работе с json теперь приходиться писать больше.

[@ruslan_yakushev]

картинка просто топ!

[@t0digital]

Спасибооо!

[@MrPeredreifus]

Тогда получается это связь "один к нулю/одному" =)

[@sngingmanticorefromvietnam893]

подскажите название видео, где вы говорите про сбор постгри с исходников, не нашел в описании(:

[@developerdiary3136]

Да это в интернете гуглится, там пару команд в принципе ввести.

[@developerdiary3136]

У автора на канале видео - ставим любой софт из исходников.

[@baturin_m]

Делаю 1к1 в случае, если используется логическая репликация таблиц в другие бд (например, для других приложений проекта), но при этом им нужны не все данные, а только основные. Логическая репликация, напомню, реплицирует выбранные таблицы только целиком. Тем самым сильно снижаю нагрузку на сеть. Да и таким образом скрываю ненужные (и местами даже нежелательные к показу) атрибуты бизнес-сущностей от клиентов реплик

[@t0digital]

Тоже мысль, да!

[@ntvisigoth]

Логическую репликация имеет смысл вот по каким причинам: - На одной СУБД один порядок байт, а ну другой уже другой - На одной одна версия СУБД, а на другой совсем другая - На одной один CPU, а другой совсем другой Другими словами, когда вы сталкиваетесь с тем, что физические данные добавленные в один сервер СУБД могут быть неверно поняты на другом сервере СУБД. Если у вас подобного нет, то лучше использовать физическую репликацию. Ее обычно используют при создании кластера СУБД, когда реплика догоняет мастера и для ускорения работы репликации как раз-таки используют СУБД.

[@whintu]

Нет, необязательно целиком. Можно навесить триггер и фильтровать строки которые будут реплицированы.

[@baturin_m]

@@whintu хм, чот не нашел такого в документации А даже если б и нашел, то у нас тут речь о сокращении столбцов (читай атрибутов), а не строк

[@blacksun9518]

Теперь понятно чего он так вес набрал - женился))

[@PlayGameToday]

Хз, о чем ты. Выглядит как и раньше

[@MrNagios]

Привет, может расскажешь как Джангу хостить на Селектеле? Или ФастАПИ

[@t0digital]

уже есть такие: - kzbin.info/www/bejne/fH3MfIeApt6srNU - kzbin.info/www/bejne/q4m3i4Crp7JjfLs - kzbin.info/www/bejne/oZTPiqCYaZx_isk

[@Guitarist138]

Таки почему в первом запросе не было записей во временные файлы?

[@t0digital]

Потому что для сортировки достаточно было выделенной памяти 4 мегабайта.

[@igorek1794]

это актуально только для PostgreSQL или применимо и для MySQL?

[@t0digital]

это плюс-минус актуально и для других реляционных строковых СУБД (которые хранят информацию построчно, а не поколоночно)

[@igorek1794]

@@t0digital о, спасибо за ответ) думаю я сам ещё дополнительно проведу тесты с mysql. интересны результаты

[@artydevco]

Как правильно сконфигурировать work_mem?

[@t0digital]

Экспериментами. Если он будет слишком маленький - некоторые сортировки и другие операции будут залезать на диск для кеширования, что медленно. Если слишком большой - то RAM будет не хватать для всех параллельно выполняемых запросов. На OLTP в районе 4 мегабайт и держат, на OLAP поднимают до 64 мегабайт, например. Впрочем вот это "медленно" это не всегда проблема. Ну, вместо 80мс какая-то табличка грузися 200мс. Не всегда это проблема.

[@artydevco]

@@t0digital у меня аналитическая бд 1.5тб, изменение этого параметра может ускорить мои запросы?

[@t0digital]

выдели самые тяжелые запросы (их можно найти в статистике постгреса), посмотри их explain (analyze, buffers), если увидишь уход на диск временных данных - то да, поможет

[@artydevco]

@@t0digital есть ли смысл выделять под это дело десятки гигабайт? (Сервер позволяет)

[@t0digital]

надо тестировать. Но, кажется, это уж too much

[@banzaika]

нету комманд для новичков в описании((

[@t0digital]

Спасибо, сейчас добавлю

[@maksimmuruev423]

Хороший ролик. но не раскрыта тема с JSONP полем! А это в наше время популярно. Если я правильно понимаю там два сценария когда поле маленькое и когда со временем оно раздулось большие 8k ;).

[@darklingmacmillan5334]

Расскажи свое отношение к сертификации Postgres Pro , стоит не стоит, итп

[@t0digital]

о чем речь, что за сертификация постгрес? Стоит ли покупать платный Postgres от Postgres Professional?

[@sergeyfilatov3027]

Информация интересная и полезная, но 90%+ процентов проектов в интернете вряд ли дорастают до масштабов когда это сильно скажется на производительности, а гемора с таким разбиением будет больше, поэтому я бы оставил как есть считая это ранней излишней оптимизацией

[@t0digital]

Гемор штука такая. Связь 1-1 позволяет хорошо разделить данные, так, что с ними работать будет понятно как, понятно, где что лежит. А когда 82 или 822 колонки в таблице - работать с этим сильно менее приятно

[@supram941g5]

@@t0digital Связь 1 к 1 добавляет кучу проблем: 1) Усложняются SQL-запросы 2) Усложняется маппинг на сущность в коде 3) Увеличивается размер индексов 4) Усложняется понимание (я дважды переспрошу у человека, который сделал отдельную таблицу, зачем он это сделал) Все эти проблемы вы получите сразу, и всё это ради того, чтобы было поприятнее работать в SQL-клиенте, Веб-разработчики работают в консоли по необходимости, т. е. редко, и в тот самый раз смирятся и таки напишут все нужные поля в селекте (или просто промотают результаты). Вывод очевиден: связь 1 к 1 применяется только тогда, когда человек осознанно готов мириться с недостатками, потому что есть более приоритетные задачи, безопасность и пр. (пример - комментарий выше про репликацию). Т. е. связь 1 к 1 является преждевременной оптимизацией, дающей мифический выигрыш в скорости и реальные проблемы в коде здесь и сейчас. Хорошо, что к вашему примеру в видео это не имеет никакого отношения) Может ли у сотрудника быть несколько контактов - конечно да, может ли у сотрудника быть несколько зарплат - да, если сотруднику поднимали зарплату, старая лежит рядом с соответствующей датой, может ли сотрудник быть в нескольких отделах - это реже, но тоже да. Всё ваше разделение не имеет никакого отношения к связи 1 к 1, это всё связи 1 ко многим. Более того, говорить про связь 1 к 1, а потом рассуждать про 1 к 0 некорректно (еще и людей уважаемых упоминать). Но и здесь есть важные детали, которые не были упомянуты: null поля хранятся компактно, пока в них нет данных, а битовые поля даже с данными компактны. Связь 1 к 1 - это когда нужны данные из обеих таблиц, но их почему-то две, это почти всегда плохо, а вы это новичкам советуете(

[@ОстапБендер-б9д]

У этого парня в каждом видео новый микрофон. Даже не знаю что хуже -- что я это замечаю, или что я знаю названия всех этих микрофонов.

[@t0digital]

Сейчас вот еще Rode Podmic USB купил))) чтобы вне студии без звуковухи писать

[@ОстапБендер-б9д]

@ я перебрал для дорожного сетапа кучу всего и в итоге остановился на Zoom F3 + sE8. Лучше по весу при таком качестве звука может быть только если заменить sE8 на Sennheiser 8020/40. Микрофон вожу в колбе от шипучих витаминов, а зум просто бросаю в пенал с проводами, адаптерами и тд. Но этот Rode тоже неплохо звучит на тестах в ютубе, которые я видел. Теперь думаю, может еще его попробовать в дорогу купить))

[@ДжорджИзджунглей-к7я]

Ой мА, да Алексей-то наш, потолстел то, вай йа, да как так вышло-то, что Алексей то наш располнел

[@АлмазИлалетдинов-м3х]

Кольцо на пальце просто так или можно поздравить?))

[@igorvasilev6299]

Когда у вас табличка из сотен колонок, нужно подумать об внедрении колоночной базы данных, а не связей 1 к 1 в PostgreSQL

[@MichioSempai]

Когда у вас реляционное БД единственный источник хранения данных вы не выбирайте другую БД, а оптимизируете существующую. Отдельная БД это вынужденное решение для отдельных сценариев и чаще она не подходит чем подходит.

[@АльбертБиктимиров-л7г]

Про TOAST забыл рассказать )

[@myortv_]

окей, курс продан

[@p1nkflow]

Зачем было показывать запрос с высокой селективностью, если мы изначально смотрели комбинацию данных с другими таблицами, а теперь просто достаем три поля? Нужно было показывать как достается по айдишнику вместе с инфой по департаменту, чтобы джойн был и результаты сравнивать. А так мы просто подарили результат маленькой таблице, выбрав только то, что в ней есть

[@t0digital]

Это влияет в рамках погрешности измерений. Join для коротких запросов по индексным колонкам это ерунда. EXPLAIN (analyze, buffers) SELECT e.employee_id, e.first_name, e.last_name, eh.employment_date FROM employee e JOIN employee_hierarchy eh ON e.employee_id = eh.employee_id WHERE e.employee_id=12345; 0.207 ms, Buffers: shared hit=3 read=8 --------- EXPLAIN (analyze, buffers) SELECT e.employee_id, e.first_name, e.last_name FROM employee e WHERE e.employee_id=12345; 0.038 ms, Buffers: shared hit=3 read=4 Всё в рамках одной миллисекунды.

[@pitaki]

Ну в таком случае зачем нам постгрес, когда есть кликхаус?

[@t0digital]

В каком «таком»?

[@pitaki]

@@t0digital я в том контексте, что раз мы практикуем такое дело, как узкие таблички. То, есть кликхаус, где все таблички одноколоночные. Уже не придумаешь)

[@TheDelwish]

0:37 кто так говорит что это лишнее? так вопрос даже на интервью попадался мне еще вначале карьеры. вангую - речь про разгрузку прогонки данных? ну это даже в языках программирования в той же java изучают ..великий программист азазин еще рассказывал про паттерн envelope вообще все эти анти-паттерны про одну big table видел от поврежденных в уме последователей монги. когда-то я даже считал эту бд полезной, пока не встретил разработчиков , которые делали проекты на монгах. со своим особенным мышлением.

[@forest4766]

если нет документации или она очень плохая, то разделение одной таблицы на несколько со связями 1 к 1 ооочень сильно усложняет жизнь разработчику бд. ИМХО

[@t0digital]

Ты предпочтешь таблицу из 100 колонок десяти таблицам по 10 колонок, когда колонки в 10 таблицах сгруппированы четко по совместному сценарию использования этих данных?

[@donkeyiaiaia4315]

Главная проблема, из-за которой я очень осторожно отношусь к отношению один к одному, это невозможность создания составных индексов с полями из разных таблиц. Если у вас в одной табличке лежит фамилия, допустим Иванов, которых в нашей стране миллион, а в другой день рождения 21.10.1990, которых 10 000, то что бы найти всех 10 Ивановых, родившихся в этот день, вам придется перебрать минимум 10 000 записей, а при неудачном плане запроса и весь миллион. С составным индексом в пределах одной таблицы, с вероятностью 99,999% придется вычитать всего 10 записей. Какие бы они ни были широкие, это все равно будет на порядки быстрее.

[@t0digital]

Данные, которые часто запрашиваются вместе, стоит вместе и хранить, конечно. А если это нечастяй запрос, то материализованная вьюшка с данными обоих таблиц и индексом на ней поможет решить эту проблему.

[@donkeyiaiaia4315]

@@t0digital в моем примере вопрос, скорее, не в запрашиваемости данных из нескольких таблиц, а в их одновременном участии в условии where. И одновременно низкой селективности. На самом деле, проблема такого рода у нас встречалась в Оракле и довольно массово, из-за неудачного дизайна базы предыдущими разработчиками. А усугублялось все особенностью Оракла, который привязывал план запроса к его тексту один раз каждое утро. И в неудачные дни использовался как раз индекс по фамилии, если она была достаточно редкой в статистике, а на Ивановых потом подписали запросы. Приходилось хинтами ставить вперед таблицу с днями рождения, там распределение более равномерное.

[@capstanfearless]

Здарова котаны!

[@pubpoltv]

текст кушает больше всех, по-этому его есть смысл выносить, тем более если его много, он не имеет первостепенного значения. у нас таблица доросла до 270 полей ;) насчет постгрес не знаю, но слышал что перкона собирала mysql в том числе потому, что дефолтные параметры компиляции бесплатной версии были подрезаны и отличались от энтерпрайс

[@developerdiary3136]

Видео про базы данных. Комментаторы: женился ? потолстел?

[@Aik2029]

А данный чувак даже в чем-то разбирается

[@t0digital]

капелюшечку малую

[@КоньЛюдоед-ф6ф]

Напрягся на фразе СБУшный КЭШ

[@PrefixKrema]

Департамент это разве связь один к одному? Это же один ко многим.

[@t0digital]

Тут не показан справочник департаментов, таблица department не показана, показана только колонка department_id, которая Foreign Key на этот справочник департаментов. Связь сотрудник-департамент, конечно, многие к одному

[@sammak3961]

я даже понял зачем бд в в принципе. леша держит марку

[@gulyshalkashhide]

Нальзя не обратить внимание на то, как после активной жестикуляции и её прекращения с опорой на стол, стол начинает проседать вниз.___. Мне за него честно говоря страшно. Яб стопочку книжек под него положил

[@t0digital]

это металлическая столешница длинная, закрепленная на другой части стола. С ней всё в порядке:)

[@sikelmon]

Котан женился. Поздравлямс.

[@АзатИмаев-ь4п]

Я оказывается вообще не знаю sql o.o

[@ntvisigoth]

Если честно, то про 1 к 1 крайне плохо рассказано. На первый план выдвинуты технические подробности. Тех.детали, конечно, очень полезно знать, но вот ожидалось про 1к1, а не про них :)

[@t0digital]

0:27

[@angry_cat-fi5up]

Баланс белого в зелень ушел на видео :(

[@jurisjupiter7129]

Источник знания!

[@КоньЛюдоед-ф6ф]

Открыл видео еще раз и обнаружил что не поставил лайк. очень стыдно - исправляюсь

[@ПавелГорюнов-п3в]

Работаю разработчиком BI, все правильно 1 к 1 если есть такая связь с одной таблицей нет смысла эти сущности держать по отдельности, всегда их схлопываю в одну таблицу. Даже с точки зрения моделирования это гораздо удобнее.

[@ilamiha]

первый

[@andriidrihulias6197]

А в индексе не забыл добавить и поле для ордера 😅

[@Владислав-т6р8х]

Лицо уже стало 1 к 1

[@t0digital]

Ещё!

[@С.Семенчук]

Замерять время выполнения на виртуалке, самое главное с виртуальным диском, это пять. Время в 10 раз скачет не из-за погрешности, а из-за влияния сторонней нагрузки на разделяемых ресурсах.

[@t0digital]

в миллион раз время скачет, ага-ага

[@КириллМеха]

Пока не совсем понимаю, чем one2one превосходит many2one, ведь они идентичны по структуре. Нет, за ролик спасибо, приятно смотреть такой уровень профессионализма. Но ощущение кликабельного заголовка для привлечения лоха (меня😢) теперь присутствует. Я работаю с orm в которой не представлена связь o2o, мы просто m2o используем. Даже unique не приходилось ни разу добавлять.

[@t0digital]

Где вы тут кликбейт увидели? 1-1 и 1-many это разные типы связи с разным логическим смыслом, как их сравнивать вообще?

[@КириллМеха]

@@t0digital Если под практическим смыслом вы имеете ввиду область применения, то понятно, что o2o ограничен в применении, но пока не вижу приципиальной причины по которой нельзя m2o применить вместо o2o. Меня больше интересует разница в производительности в данном случае. Посмотрел приложенные к ролику запросы (спасибо за такое качество контента), увидел, что foreign key реализован как primary key. Вот тут у меня не достает понимания. primary key, кажется, автоматически индексируется. Но индекс можно добавить и на простое foreign key поле. Может быть, что поиск по primary key полю идет несколько иначе и при нахождении 1 элемента поиск прекращается. Тогда, конечно, поиск будет быстрее, чем по просто foreign key integer полю и я приношу изменения. Но если нет, тогда не знаю почему бы m2o не использовать для тех же целей.

[@t0digital]

Вы пишете в начальном комменте «не понимаю чем o2o превосходит many to one». В видео не идет такого сравнения. Это как сравнивать вычитание и умножение. Что же лучше?

[@КириллМеха]

@@t0digital ок, думаю, я вас понял. Спасибо за интересный ролик)

[@Bunkerniy_Gadenish]

Мне кажется или котан разжирел?

[@margojazny]

Разжирел, поседел, постарел. Факт.

[@DAJakaRedAries]

Время летит

[@АндрейКоролев-з8о]

фу, как бестактно

[@Bunkerniy_Gadenish]

@@АндрейКоролев-з8о уйди прааативный скуф

[@thelookin8237]

Не разжирел, а набрал авторитета

[@whosane9923]

Удивительно, что кто-то считает, что один на один выйти это плохо😂 Даги ,что ли😂😂😂