Удивительное и невероятное о первичных ключах PostgreSQL: serial, bigserial, UUID v4, ULID, UUID v6

Поділитися
Вставка
  • Опубліковано 19 чер 2024
  • Всё о первичных ключах в PostgreSQL. Простые и составные, естественные и искусственные, искусственные числовые, UUID v4, ULID, UUID v6 - в чём разница и когда что выбирать.
    Мой курс «Хардкорная веб-разработка» - course.to.digital
    Книжный клуб:
    t.me/t0digital/528
    botanim.to.digital/
    botanim_to_digital_bot.t.me/
    ULID для PostgreSQL:
    github.com/geckoboard/pgulid/... (но возвращает text)
    UUID v6 для PostgreSQL:
    gist.github.com/fabiolimace/5...
    00:00:00 План
    00:00:45 Что такое первичный ключ
    00:00:44 Простые и составные ключи
    00:02:53 Естественные и искусственные ключи
    00:07:04 Что лучше - естественные или искусственные ключи?
    00:14:21 UUID, GUID
    00:17:08 Преимущества UUID в качестве первичного ключа
    00:19:55 Недостатки UUID в качестве первичного ключа
    00:26:26 CLUSTER
    00:27:55 ULID
    00:31:24 UUID v6
    00:32:31 Префиксы первичных ключей
    00:35:55 Реализация естественного ключа
    00:36:36 Реализация ключа числовой последовательности
    00:40:02 Реализация IDENTITY COLUMN
    00:41:50 Реализация UUID v4
    00:43:25 Реализация UUID v6
    00:45:17 Размер данных
    00:47:22 Резюме
    00:49:50 Благодарность
    /****************** about ******************/
    Меня зовут Алексей Голобурдин, я программирую с 2004 года и на этом канале делюсь своим опытом. Я основатель и руководитель компаний:
    - Диджитализируй digitalize.team, разрабатываем сложные IT системы для бизнеса;
    - Salesbeat salesbeat.pro, комплексный модуль доставки для интернет магазинов.
    Telegram канал - t.me/t0digital
    ВК - digitalize.team
    RuTube - rutube.ru/channel/24802975/ab...
    Дзен - dzen.ru/id/6235d32cb64df01e6e...

КОМЕНТАРІ • 291

  • @Erwin_Anderson
    @Erwin_Anderson Рік тому +35

    Топ контент, так нехватает чего то выше джуновского уровня, а не треша какой ЯП изучать новичкам.

    • @user-xp5bw5nl6i
      @user-xp5bw5nl6i Рік тому

      Просто вам не часто такое попадается. Ищите и найдёте

    • @_4ado
      @_4ado Рік тому +1

      ​@@user-xp5bw5nl6i ну не надо басней, 49.5% контента для людей уровнем выше джунов это конференции, ещё 49.5% это видосы с неподражаемым индийским акцентом по скидке за 480 рублей и 1% это видосы вроде этого

    • @Erwin_Anderson
      @Erwin_Anderson Рік тому +2

      @@user-xp5bw5nl6i Мб посоветуешь что то?)

    • @user-zf5vn2lw8b
      @user-zf5vn2lw8b Рік тому +1

      ​@@Erwin_Anderson совет один, сиди на попе ровно

  • @Vjidowkdkcpapqkfjfw
    @Vjidowkdkcpapqkfjfw Рік тому +65

    Я так понял, после прочтения книжки по постгрес Алексей открыл для себя что-то новое и интересное и решил поделиться этим с остальными) спасибо большое!

    • @sio80orel
      @sio80orel Рік тому +12

      хоть кто-то читает эти унылые книжки)

    • @MrLotrus
      @MrLotrus Рік тому +3

      Алексей дал значительно больше чем там есть

    • @codingfox
      @codingfox Рік тому +1

      @@sio80orel унылые можно не читать) про книжку о postgres я бы такого не сказал

  • @user-wk3nu3ud2u
    @user-wk3nu3ud2u Рік тому +4

    Спасибо, полезно! Мозг прям возрадовался приятной и понятной подаче материала! 👍

  • @jjsampo
    @jjsampo Рік тому

    Спасибо! Как раз сейчас тема MySQL в ПТУ прохожу. Ну и вообще курс, ваш, очень помогает.

  • @ivanmatew568
    @ivanmatew568 Рік тому

    Спасибо! Очень полезно! Думал, что давно всё знаю по этой теме.

  • @maxx27i
    @maxx27i Рік тому +1

    Спасибо! Интересно было послушать по UUID и всё с ними связанное. Понравилось, что осветили плюсы и минусы каждого подхода/типа. 👍

  • @user-el1fy2ob4d
    @user-el1fy2ob4d Рік тому +3

    Большое спасибо. Очень полезная информация

  • @user-ly6jh3pc6z
    @user-ly6jh3pc6z Рік тому

    Спасибо, тебе за такой ролик, узнал для себя много нового. Делай дальше, у тебя это круто получается

  • @tiktoker797
    @tiktoker797 Рік тому

    Очень полезная информация. Буду использовать в своем дипломе)

  • @rumartru
    @rumartru Рік тому

    Спасибо, было познавательно! Отличное видео.

  • @vmajura
    @vmajura Рік тому

    От души спасибо, очень легко и интересно рассказываешь.

  • @fl1lame
    @fl1lame Рік тому

    Сел покушать, а тут и годный контент подъехал. Сразу лайк!

  • @alexgorodecky1661
    @alexgorodecky1661 Рік тому

    Очень качественный материал 👍 спасибо

  • @bezborodovanton
    @bezborodovanton 10 місяців тому

    Большое спасибо за вашу работу. Отличное видео, очень полезный материал!

    • @t0digital
      @t0digital  10 місяців тому

      Спасибо!

  • @enetWatch
    @enetWatch Рік тому

    Это просто охуительно, бесконечно великолепно! Спасибо за просветление

  • @gnompirogov9259
    @gnompirogov9259 Рік тому +2

    Спасибо за Primary key. интересные мысли, рассуждения

  • @_garik__
    @_garik__ Рік тому

    Спасибо, было очень интересно и полезно!

  • @maxzhenzhera
    @maxzhenzhera Рік тому

    Спасибо, очень информативно!)

  • @sevashpun
    @sevashpun Рік тому

    👍Спасибо большое за видео. Для себя узнал несколько полезных штучек! Алексей, ты крут!✌😁

  • @shamanskiy
    @shamanskiy Рік тому +7

    Алексей! Доброго времени. Внедрю пожелание лайфхака. Следующее видео делайте в соседней комнате. Мы-же тоже дзырим ваши замечательные апартаменты. Пыточную из прошлых видео изучили, теперь понятно место откуда вещали прошлые видосы.
    Похоже что дальняя коричневая дверь стоит на вентиляции микроклимата. Фигасе. Спасибо за идею. За окна понятно, но двери - это свежо!😂
    Отличный контент. Ну сказать что-нибудь надо, вот и сказал. Вот...

  • @NormalniyChelovek
    @NormalniyChelovek 5 місяців тому +1

    Отлично рассказан материал, коммент для активности.

  • @morok-com
    @morok-com Рік тому +3

    Я только недавно начал изучать PostgreSQL, но некоторые моменты из видео заставили более внимательно относиться к структуре БД.

  • @Aticinsane
    @Aticinsane Рік тому

    Очень полезно! Спасибо!

  • @AlexandrZverev
    @AlexandrZverev Рік тому

    Доступный и подробный разбор вариантов первичных ключей, спасибо за информацию! Наверное нет смысла спорить о применении в первичных ключах int или даже smallint, потому что если такая надобность будет, то разработчик это увидит и применит. А кто-то посчитает что необходимости применения 2-х или 4-х байтового числового первичного ключа не случается никогда.

    • @vryaboshapko
      @vryaboshapko Рік тому +1

      Я знаю примерно три случая, когда можно использовать small int в качестве первичного ключа, и во всех трёх случаях есть решение в виде естественного аналога: это списки валют, стран и языков. На все три есть ISO с буквенными кодами, и такие коды будут сильно удобнее, потому что их после минимальной тренировки может читать человек. Не то, чтобы я утверждаю, что small int категорически не нужен, просто вспонилось несколько частных случаев.

  • @vladimireliseev7602
    @vladimireliseev7602 Рік тому

    Спасибо за видео!
    У меня тоже была как проблема с инкрементом sequence, когда я прям на горячем проде с 150k rpc в секунду добавил строку вручную с явным указанием id.
    И как посыпались ошибки! Ух... Хорошо быстро поправил sequence номер.

  • @funkytapir
    @funkytapir Рік тому

    Спасибо большое! Было очень интересно и познавательно, хоть я и мобильный разработчик)

  • @pep421
    @pep421 Рік тому

    Спасибо, много нового узнал.

  • @revoluxe
    @revoluxe Рік тому

    Это я люблю, спасибо!

  • @vladislavmikhailov
    @vladislavmikhailov Рік тому +2

    Ржу нимагу! "Но вот на практике нифига, нифига!" ))
    Классно делаешь ролики, много информации и весело! Продолжай в том же духе! :D

  • @ivantokariuk8725
    @ivantokariuk8725 Рік тому +2

    Круто :)

  • @user-jl9in3hh1s
    @user-jl9in3hh1s Рік тому +6

    Сначала накачал с трекеров терабайты обучащих курсов от инфоцыган теперь позатер их и смотрю ваши ролики. КПД намного выше. Большое спасибо.

  • @user-kw4kp7eq9m
    @user-kw4kp7eq9m Рік тому

    Благодарю!

  • @Coreduo
    @Coreduo Рік тому

    Сразу лайк!

  • @user-xp5bw5nl6i
    @user-xp5bw5nl6i Рік тому

    Спасибо за информацию

  • @user-hy4in3ty3l
    @user-hy4in3ty3l Рік тому

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

  • @vktrl736
    @vktrl736 Рік тому

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

  • @user-jf4qc2ic4k
    @user-jf4qc2ic4k Рік тому +1

    Классный первичный ключ - сотовый телефон
    Только у пользователя может быть несколько телефонов, ну и телефон можно потерять.
    На мой взгляд - Естественные ключи использовать крайне ненадежно.
    Вы должны быть уверены, что естественный ключ уникален в рамках проекта, концов которой не видно. (Подразумевается что вы работаете в проекте, а не пришлый наемник для решения одной задачи)
    Префиксы в начале - это реинкарнация Венгерской нотации от MS 😃

    • @t0digital
      @t0digital  Рік тому

      Один телефон может быть главным, остальные будут сохранены дополнительно (если нужно их сохранять). Тут больший вопрос по смене телефона, если он PK, то надо будет менять потенциально много записей в разных таблицах, что может быть тяжело. Поэтому пример с телефоном может быть не лучший, да, но мне важнее было показать суть.

  • @alexalekseichuk5737
    @alexalekseichuk5737 Рік тому +2

    Если phone_num PK, то чел. уже не сможет его поменять. PK -- это не только UNIQUE NOT NULL, но ещё и read-only. Всё же не нужно юзать phone_num в качестве PK. Это сущность/запись клиент-человек. Даже здравый смысл подсказывает нам, что нельзя его отождествлять/идентифицировать/привязывать к номеру телефона.

  • @user-tr7lu4xr2u
    @user-tr7lu4xr2u Рік тому +2

    Первичные ключи в маленьких табличках часто бывают внешними ключами в больших. И вот там можно много сэкономить.

  • @vryaboshapko
    @vryaboshapko Рік тому +3

    Частный случай префиксных ключей - это номера паспортов и других подобных документов. Они содержат серию и номер. Серия назначена по территориальному принципу, а номер - это просто счётчик. То есть, каждому актору, имеющему право генерировать первичный ключ, присваиватеся свой префикс, а он внутри себя следит за простым счётчиком. Причём, счётчик персистится с помощью write ahead log: каждый новый паспорт заносится в журнал, и ему присваивается номер на единичку больше от предыдущего занесённого. Ничто не ново под Луной, как говорится)

  • @pavel_dev
    @pavel_dev Рік тому

    Классные видосы для гиков у тебя. Я подписан

  • @basil0607
    @basil0607 3 місяці тому

    12:50 - при этом надо понимать, что естественный первичный ключ для справочника тех же пользователей - это та еще мина замедленного действия (помимо потребности хранить длиннющий UID или 11 знаков номера телефона во всех связанных таблицах, где могут быть сотни миллионов записей). Из того же примера в видео: вот пользователь деактивировал сим-карту и мобильный оператор продал этот номер спустя время новому физ.лицу :) Логика сломается уже на этапе регистрации в приложении где-то на бэкенде при обращении к базе. Про момент защиты персональных данных уже в ролике озвучено - тут сразу получается не вариант с естественным первичным ключом

  • @mkhnuser
    @mkhnuser Рік тому

    Хороший материал, которого всегда не хватает. Кстати, а какую вы тему используете для psql? Вижу, что у вас есть автодополнения и подсветка.

  • @alexeyradchenko9967
    @alexeyradchenko9967 Рік тому +1

    По примеру с естественным ключом в виде номера телефона: - очень удобно, особенно когда пользователь хочет поменять номер телефона. Т.е. что проще, посмотреть по номеру телефона id и далее делать все тоже самое по id или при смене телефона иметь ад по сохранению целостности данных? Проблема в том, что зачастую многие естественные ключи не являются абсолютно константными и это создает гораздо большую проблему, чем та польза, о которой говориться. P.S. да, я читал статью про IDотов, к сожалению не могу придумать каламбур про Естественно-отов =)

  • @enetWatch
    @enetWatch Рік тому +3

    Очень неплохо бы разобрать тему uuid6 в сторону ускорения до uuid7 и 8

  • @avorion-ru
    @avorion-ru Рік тому

    Приветствую! Спасибо за видос, очень актуально и полезно. Интересно ваше мнение по вопросу: где удобнее всего и эффективнее разрабатывать схему БД? В кансоле сразу, или может в pgAdmin, а может по старинке на листочке схему рисовать?)

    • @t0digital
      @t0digital  Рік тому +3

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

  • @user-vz3uy3hh2q
    @user-vz3uy3hh2q Рік тому +10

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

    • @andreybogdanov3
      @andreybogdanov3 Рік тому +2

      on update cascade 😉

    • @vryaboshapko
      @vryaboshapko Рік тому +2

      Вцелом согласен, но тут стоит ещё заметить, что номер телефона, номер паспорта, мыло, номер аськи - это всё примеры неудачного естественного ключа, как раз потому, что они могут меняться. Примеры более удачных ключей - это налоговые номера (ИНН, TIN, NIF и др.) и номера социального стразования (СНИЛС, SSN и др.), так как они назначаются один раз и на всю жизнь.

    • @user-vz3uy3hh2q
      @user-vz3uy3hh2q Рік тому

      @@andreybogdanov3 спасибо, я что то забыл про такую возможность

    • @user-vz3uy3hh2q
      @user-vz3uy3hh2q Рік тому +4

      ​@@vryaboshapko в таких ключах есть ещё одна проблема. Это опечатки, а ключ уникальный. И вот оператор вводит, например СНИЛС или номер серию паспорта, если это составной естественный ключ. И делает там опечатку в одной цифре. А в другую организацию приходит человек именно с таким номером, например паспорта. И в той организации ввести его данные не могут и разобраться без помощи разработчиков тоже не могут, потому что опечатку сделала другая организация. В итоге в базе данные не правильные и ввести правильные нельзя. В общем использовать естественные ключи можно, но как по мне с таким количеством нюансов - ну его...

    • @vryaboshapko
      @vryaboshapko Рік тому +3

      @@user-vz3uy3hh2q для этого в СНИЛС и ИНН зашита проверка целостности. Грубо говоря, если хитро сложить первые цифры, получится последняя (точные алгоритмы публичны и легко гуглятся). Такая же, кстати, есть для номеров баноковских карт, но это не относится к теме естественных ключей). Плюс есть публичные базы данных, по которым можно провалидировать, например, что номер соответствует ФИО или дате рождения. А номер паспорта точно нельзя использовать как естественный ключ (даже как часть составного) по той же причине, что и номер телефона: он меняется. Это уникальный номер документа, а не человека.

  • @user-to8dm8tv4g
    @user-to8dm8tv4g Рік тому

    спасибо!

  • @user-lv3hn6uz4e
    @user-lv3hn6uz4e Рік тому +6

    23:00 как ни странно иногда вставка уидов может быть быстрее чем вставка в условный bigint. Особенно если база уже большая и не новая, по той же как раз причине, что вы и описали.
    При очень интенсивной вставке, если вставка идёт одновременно из множества сессий, то возможны проблемы за конкурентный доступ последней страницы в которую данные льются, а при уидах вставка происходит в рандомные страницы в разных местах индекса и сессии друг другу не мешают)

    • @alexeyvoronin4651
      @alexeyvoronin4651 Рік тому

      Вопрос не в вставке, а в последующем использовании. Чем тяжелее ключ, тем тяжелее join .

    • @MichioSempai
      @MichioSempai 9 місяців тому

      При интенсивной вставке в таблицу где pk - uuid, будет происходить очень частая и тяжёлая перестройка индекса, из-за этого как раз и может происходить существенная просадка по производительности.

  • @fixedlearner
    @fixedlearner Рік тому

    Про использование identity column было очень интересно. Не был в курсе подобной опции. Впрочем, при грамотном использовании serial не доставит никаких проблем. Достаточно целиком отдать генерацию id на откуп базы данных

  • @user-ec7ne8rn5v
    @user-ec7ne8rn5v Рік тому +4

    Для тех кто не знал, количество номеров ограничено. Операторы очень часто перепродают номера, которыми давно не пользовались. Така ситуация буквально с моим номером произошла. Год не пользовались симкой, не пополнялся баланс и у меня её номер забрали и отдали другому человеку

    • @vryaboshapko
      @vryaboshapko Рік тому

      Перепродажа номеров - это скорее не от ограниченности номерного пространства, а от экономии. В России телефонный номер состоит из 10 цифр, это 10 миллиардов вариантов, это больше, чем людей на земле. Даже если взять, что у мобильных номеров первая цифра всегда 9, всё равно остаётся 1 миллиард номеров, это больше, чем по 7 номеров на каждого жителя страны. Но расширение номерного пространства стоит денег (нужно «купить» ещё один префикс), так что логично использовать номера отключённых абонентов.

  • @andreybagulnikov5404
    @andreybagulnikov5404 Рік тому

    Капец ты гений какой то)

  • @fleapse
    @fleapse 2 місяці тому

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

  • @user-jd4rl7im6d
    @user-jd4rl7im6d Рік тому +1

    "Индекс - это отсортированная структура данных" - это справедливо для b-tree, но есть ведь индекс, основанный на хэш-мапе

  • @ntvisigoth
    @ntvisigoth Рік тому

    Алексей, а как ты настроил code-completion при работе с psql в терминале?

  • @zloysanta3391
    @zloysanta3391 Рік тому +1

    По поводу always generate. А что если нам требуется восстановить таблицу из бэкапа и при этом в ней есть пропуски(удаленные записи)?

  • @helisergey
    @helisergey Рік тому

    А есть видео где рассказывается про настройку терминала? Что бы так же дополнение запросов было? Или же это именно дополнение из консоли постгресс ?

  • @EdwardNorthwind
    @EdwardNorthwind Рік тому

    UUID v6 выглядит перспективно, но я бы вообще пошел дальше и использовал nanoTime, а для формирования рандомной части оставил последние 11 байт (12 символов).

  • @RexerNotes
    @RexerNotes Рік тому +1

    Мысль про ключи естественные ок, но пример с номером телефона плох(опасен). Клиент может захотеть сменить номер телефона и вот тут придётся менять ваш PK, что выльется в проблемы и боль миграций.

  • @Iva666ka
    @Iva666ka Рік тому

    Как можно проверить, что uuid_v6 (ulid, objectId) в качестве primary_key работает быстрее на больших объемах данных, чем uuid v4? Какой тест тут лучше применить?
    Для записи приходит в голову что-то типа "генерируем 10ккк uuidV4, затем в другой таблице 10ккк uuidV6, сравниваем время". А для чтения это как лучше проверить?

  • @enetWatch
    @enetWatch Рік тому

    А что если префиксную часть сделать модифицируемой по длине? Тогда мы сможем выбирать приоритет на скорость записи или скорость чтения из БД соответственно по скорости формирования и чтения индекса

  • @michaeldeoz
    @michaeldeoz Рік тому +1

    Пример с телефоном очень показательный. Есть у нас история действий пользователей с неким номером телефона. Казалось бы удобно. Но люди бывают что меняют номера телефонов. и если пользователь сменит свой телефон он лишиться всей своей истории.

  • @Sergey-jq5kz
    @Sergey-jq5kz Рік тому

    а если использовать "generated always as identity" то не будет проблем при импорте? Например если одна запись удалена просто заново сгенерировать не вариант.

  • @telyuk.a
    @telyuk.a Рік тому

    Алексей, подскажите пожалуйста, насколько будет эффективен индекс для поля, ну допустим varchar(300)?

    • @t0digital
      @t0digital  Рік тому +1

      Да просто потестируйте сами. Сгенерите данных, сколько у вас будет в табличке, сделайте analyze, чтобы обновилась статистика, и сравните выборку без индекса и с индексом. Индекс - не гарантия эффективного выполнения запроса, он даже не обязательно будет использоваться в конкретном запросе, это как планировщик решит.

  • @ysomad
    @ysomad Рік тому

    21:01 - чтобы ориентироваться по времени как вариант можно использовать uuid v7

  • @Evervess179
    @Evervess179 Рік тому

    крутая картинка. кач хорош

  • @user-jh1ry3uf4u
    @user-jh1ry3uf4u Рік тому +3

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

    • @romul23
      @romul23 Рік тому

      Postgresql автоматически создает индекс для primary key. Поиск по индексированному полю работает быстро.

    • @programisli
      @programisli Рік тому +4

      UUID это не строки, а 128 бит и нужно сравнивать 128 бит, что достаточно быстро. Но int будет занимать меньше месте на диске и если это внешний ключ то по числу поиск будет чуть более эффективнее, потому что меньше нужно держать в памяти или читать с диска. Просто индекс будет компактнее

    • @cristianglodeanu2329
      @cristianglodeanu2329 Рік тому

      @@programisli пхах, какраз когда прочитал 128 бит, в видосе на 20:13 прозвучало "весит 128 бит"

    • @vryaboshapko
      @vryaboshapko Рік тому

      128 бит - это 16 байт. То есть, сравнение двух UUID-ов занимает столько же времени, сколько сравнение двух строк из 16 символов (если речь не про юникод, конечно). Но стандартоне текстовое представление UUID-а (123e4567-e89b-12d3-a456-426614174000) - это 36 байт, то есть, сравнение двух строковых представлений UUID-ов занимает больше времени, чем сравнение двух честных UUID-ов. Кроме того, UUID в памяти может быть представлен не как набор байт, а, например, как два лонга (64-битные целые), и тогда сравнене будет ещё быстрее, потому что современные 64-битные процессоры могу сравнивать 64-битные целые за один такт.

    • @stripeberry
      @stripeberry Рік тому +1

      По скорости инкримент будет в десятки раз быстрее, поэтому делают два ключа, id и uuid, один для внутренних релейшенов, другой для внешки

  • @gerzzog88
    @gerzzog88 Рік тому

    Прикольное худи Lacoste. Подскажи, модель или серийник)

  • @user-cm7mb3vr2y
    @user-cm7mb3vr2y 6 місяців тому

    Полезное видео, спасибо! А где можно найти параметр, отвечающий за такую зеленую подсветку кода?

    • @t0digital
      @t0digital  6 місяців тому

      Спасибо! Это pgcli

  • @user-rz6jj3ky3e
    @user-rz6jj3ky3e Рік тому

    Круто!
    А про индексы планируется видео?

  • @jamjam3337
    @jamjam3337 Рік тому

    👏

  • @uicodeuz
    @uicodeuz Рік тому

    Кайф

  • @PrefixKrema
    @PrefixKrema Рік тому

    А почему у вас PSQL такой красывый?
    На первой минуте. Или это для маков эксклюзив?

  • @vyacheslavzakharov9600
    @vyacheslavzakharov9600 4 місяці тому

    До этого видео относился к UUID как к безумной глупости. Побежал добавлять это дело к себе в петпроект

  • @emutant01
    @emutant01 Рік тому

    9:30 т.е. create view с join и работать так же с телефоном но с view нет?

    • @t0digital
      @t0digital  Рік тому

      не понял вопрос

  • @sergeykaprantsev5192
    @sergeykaprantsev5192 Рік тому

    как в ПГ при импорте дампа сделать ремап имени схемы по аналогии с oracle remap_schema? =(

  • @kl45gp
    @kl45gp Рік тому +2

    4:08 а потом пользователь захочет сменить почту) и полетел наш первичный ключ во всех связных таблцах. Первичный ключ лучше всегда делать искусственным.

    • @programisli
      @programisli Рік тому

      Конечно это просто пример, хотя не вижу проблем с заменой email, это же не автоинкремент и поле изменять можно. Будут проблемы с обновлением связей - да, но решаемо. Никогда не говори всегда. Возможно email был не самым лучшим примером, но вот например у тебя есть таблица стран и у стран есть Abbreviation - Name со значениями RU - Россия, US - США. Не нужен тут искусственный ключ, если первичный ключ на Abbreviation будет уникальным, и гарантирует уникальность Abreviation.

    • @kl45gp
      @kl45gp Рік тому

      @@programisliтак вот чтобы потом не думать как исправлять, надо тупо делать искусственный ключ. По этой же причине надо не думать и делать сразу микросервисную архетиктуру, потому что сделав монолит через года можно сильно пожалеть.Сколько таких случае когда куда не глянь а все монолит свой пилят на сервисы? Всетоки есть практики - железны, которые уже написаны кровью

    • @kl45gp
      @kl45gp Рік тому +1

      @@programisli а потом в один прекрасный момент у страны всеже поменяется Abbreviation-Name) Или изменится вид с двух значного на трехзначный.

    • @t0digital
      @t0digital  Рік тому

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

    • @kl45gp
      @kl45gp Рік тому +1

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

  • @Deletedeletedelete
    @Deletedeletedelete Рік тому

    Как в постгре работают индексы под капотом уже был видос? :)

  • @VadimPrudivus
    @VadimPrudivus Рік тому

    Спасибо, послушал с интересом. Единственно не согласен с настойчивой рекомендацией использовать bigint в качестве ПК. Обычного int хватает в 99%, если только вы не собираетесь автоматизировать весь мир. В любом случае нужно понимать на какие объемы проектируется система, и принимать проектные решения исходя из этого.
    Еще раз спасибо, хорошая подача материала!

    • @vladislavstepanov7591
      @vladislavstepanov7591 10 місяців тому

      Накладные ресурсы которые уйдут на bigint не сравнятся с болью перелапачивать бд и менять типы с int на bigint

  • @dilmurod9539
    @dilmurod9539 Рік тому

    Просто для заметки:
    Если x = "Иногда" и y = "Всегда" то
    y = K * x, при условии К - частота случае "Иногда" и она стремиться к бесконечности )))))

  • @brenkovd
    @brenkovd Рік тому

    Я извиняюсь, только включил ролик и увидел прикольный вывод в консоли команд, это что за утилита?
    pgcli , увидел дальше в видео

    • @vyacheslavkapitonov9677
      @vyacheslavkapitonov9677 Рік тому

      pgcli

    • @t0digital
      @t0digital  Рік тому

      Да, она. На питоне написана, немного багнутая, отправлял туда PR)

  • @danilgalkin9011
    @danilgalkin9011 Рік тому +1

    Будет ли видео про обновление питона до 3.12?

  • @maksimkuznetsov2132
    @maksimkuznetsov2132 Рік тому

    Ого, а интересно, как консоль на маке собирает таблицу для оторбражения? Красиво же выглядит, не то, что поплывшие таблицы на символах -- |
    А не, тоже плывёт.

  • @maksimkuznetsov2132
    @maksimkuznetsov2132 Рік тому

    Знаю такой прикол, когда мы делаем UID-ы самостоятельно, которые получаются из витовых склеек из других полей. Не знаю правда зачем.

  • @tirnik707
    @tirnik707 Рік тому

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

    • @t0digital
      @t0digital  Рік тому

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

    • @tirnik707
      @tirnik707 Рік тому

      @@t0digital Имею ввиду, что бывают случаи, когда генерация айди не эффективна на уровне базы. Например кейс когда нужен высокий перфоманс и применяется вставка батчем.

  • @pavel6981
    @pavel6981 Рік тому

    Сделай видево как быстро считать количество всех результатов выборки, с учетом фильтров, в постгресе

  • @Seniorius
    @Seniorius Рік тому +1

    Расскажи про timescaledb

  • @alexanderspeshilov839
    @alexanderspeshilov839 Рік тому

    23:32 а в чём сложность с WAL в этой модели?

  • @kl45gp
    @kl45gp Рік тому

    с таким крупным шрифтом ты очень быстро сломаешь себе глаза! 12 должен быть максимальный.

    • @t0digital
      @t0digital  Рік тому

      Шрифт для видео увеличиваю, чтобы было видно всем

  • @wskeal86
    @wskeal86 Рік тому

    У ulid есть некоторая проблема в том, что инстансы приложения генирующие улиды могут находиться на разных физических машинах с рассинхроном времени, проблему рассинхрона ещё человечество до конца не решило. Поэтому в распределенной системе не факт, что каждый следующий сгенерированный ulid будет лексикографически старше предыдущего.

    • @vladislavstepanov7591
      @vladislavstepanov7591 10 місяців тому

      Разве рассинхрон в несколько миллисекунд это проблема?

    • @wskeal86
      @wskeal86 10 місяців тому

      @@vladislavstepanov7591 фишка ULID в том, что один ULID больше другого, если он сгенерировался позже на 1мс, чем первый. Но если на разных тачках есть рассинхрон, то польза от ULID'a нивелируется и проще использовать UUID v4

  • @herman_guilliman
    @herman_guilliman Рік тому

    Хочу чтобы в кадре была красная кружка с лого "D!"

  • @user-dn8yk9wq7c
    @user-dn8yk9wq7c Рік тому

    get_random_uuid был добавлен в PostgreSQL 13

  • @granddndz
    @granddndz Рік тому

    а что делать, если юзер, которую вы определили первичным ключем номер телефона, поменял номер телефона? получается, что возможности в аккаунте на смену номера уже не будет?

    • @t0digital
      @t0digital  Рік тому +1

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

    • @kotbajan
      @kotbajan Рік тому

      Для микросервисной архитектуры, где создать общий ID для всех систем проблемно, а обрабатывать одну и ту же сущность надо - это вполне себе рабочий вариант. Широковещательным сообщением по системам разносится требование обновить PK с ON UPDATE CASCADE и должно работать. Плохой, лучше все-таки генерить сквозной ID для всех систем. И не забыть про денормализованные структуры, которая содержит те же данные, но без FK.

  • @viktor_borodin
    @viktor_borodin 3 місяці тому

    Иметь или быть* если я правильно понял, то какая книга имелась ввиду

  • @dimapiteru
    @dimapiteru Рік тому

    Говорят mongodb при частых обращениях может занимать место в ОЗУ для более быстрого ответа, наверняка ведь pg не с диска каждый раз читает? Может быть сможет кто-то пояснить?

    • @t0digital
      @t0digital  Рік тому

      Конечно, pg не с диска читает каждый раз. Кэш и всякое такое имеется

    • @nikitabugrovsky1492
      @nikitabugrovsky1492 Рік тому +2

      Когда постгресс запускается, стартует постмастер процесс. Он ждет подключения от клиентов БД. От посмастера также форкаются множество других бэкенд процессов, которые выполняют CRUD операции и разные служебные задачи типа логирования, создания WAL, репликации. Процессы, которые выполняют CRUD, имеют общий доступ к ограниченному сегменту оперативной памяти - shared buffer. Это позволяет процессу брать результаты sql запросов из оперативной памяти, если такой запрос уже был адресован БД. Если в общем буфере результата запроса не найдено, есть шанс, что результат будет найден в кэше ОС ( другой сегмент оперативки). Если нигде ничего не найдено, придется обращаться к файлу БД - это уже IO.

  • @user-ku4iu3ed9n
    @user-ku4iu3ed9n Рік тому +1

    360*1500= 540к, неплохо))

    • @t0digital
      @t0digital  Рік тому +2

      налоги, комиссии, съемка, монтаж, команда с зарплатами и 31 день работы в месяц - неплохо

  • @kirill9927
    @kirill9927 8 місяців тому

    С serial id есть проблема при миграции с сохранение id объектов.
    Плюс апишника хотять что бы id был uint64 :D

  • @user-yu2sq8fc3e
    @user-yu2sq8fc3e Рік тому

    Опечатка в назавании ULID v6?

    • @t0digital
      @t0digital  Рік тому

      Спасибо, поправил

  • @LuckyDen2012
    @LuckyDen2012 Рік тому +1

    Про телефон посмеялся :)) кто то еще делает по ним первичные ключи ? :)
    Сделали, а потом юзер перестал оплачивать телефон, компания телефон отбирает, и передает ДРУГОМУ :))) "здрасте приехали" :)

  • @user-fh6xg9pn3y
    @user-fh6xg9pn3y Рік тому

    05:57 а зачем использовать для этого именно композитный первичный ключ-то?
    Первичный ключ - он для идентификации. Для избежания дублирования просто создаёшь индекс уникальности по нужным колонкам. Это то, что делает первичный ключ, кстати.

    • @alexgorodecky1661
      @alexgorodecky1661 Рік тому

      Это порождает избыточность. Удобство искусственных первичных ключей зависит, в первую очередь, от запросов. Пример: settings - настройки с учётом года. Входить в эту таблицу мы всегда будем через , и ссылок из других таблиц на settings часто тоже нет. Итог - в данном случае лучше составной естественный ключ

    • @user-fh6xg9pn3y
      @user-fh6xg9pn3y Рік тому

      @@alexgorodecky1661 Я о другом. Выбирайте вариант, который Вам нужен. Но конкретно задача избавления от дублирования решается уникальным индексом, для неё не нужно накрывать колонки первичным ключом.