Удивительное и невероятное о первичных ключах PostgreSQL: serial, bigserial, UUID v4, ULID, UUID v6
Вставка
- Опубліковано 23 чер 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...
Топ контент, так нехватает чего то выше джуновского уровня, а не треша какой ЯП изучать новичкам.
Просто вам не часто такое попадается. Ищите и найдёте
@@user-xp5bw5nl6i ну не надо басней, 49.5% контента для людей уровнем выше джунов это конференции, ещё 49.5% это видосы с неподражаемым индийским акцентом по скидке за 480 рублей и 1% это видосы вроде этого
@@user-xp5bw5nl6i Мб посоветуешь что то?)
@@Erwin_Anderson совет один, сиди на попе ровно
Я так понял, после прочтения книжки по постгрес Алексей открыл для себя что-то новое и интересное и решил поделиться этим с остальными) спасибо большое!
хоть кто-то читает эти унылые книжки)
Алексей дал значительно больше чем там есть
@@sio80orel унылые можно не читать) про книжку о postgres я бы такого не сказал
Спасибо, полезно! Мозг прям возрадовался приятной и понятной подаче материала! 👍
Спасибо! Интересно было послушать по UUID и всё с ними связанное. Понравилось, что осветили плюсы и минусы каждого подхода/типа. 👍
Спасибо! Как раз сейчас тема MySQL в ПТУ прохожу. Ну и вообще курс, ваш, очень помогает.
Спасибо! Очень полезно! Думал, что давно всё знаю по этой теме.
Большое спасибо. Очень полезная информация
Алексей! Доброго времени. Внедрю пожелание лайфхака. Следующее видео делайте в соседней комнате. Мы-же тоже дзырим ваши замечательные апартаменты. Пыточную из прошлых видео изучили, теперь понятно место откуда вещали прошлые видосы.
Похоже что дальняя коричневая дверь стоит на вентиляции микроклимата. Фигасе. Спасибо за идею. За окна понятно, но двери - это свежо!😂
Отличный контент. Ну сказать что-нибудь надо, вот и сказал. Вот...
Спасибо, тебе за такой ролик, узнал для себя много нового. Делай дальше, у тебя это круто получается
Очень полезная информация. Буду использовать в своем дипломе)
От души спасибо, очень легко и интересно рассказываешь.
Спасибо, было познавательно! Отличное видео.
Сел покушать, а тут и годный контент подъехал. Сразу лайк!
Это просто охуительно, бесконечно великолепно! Спасибо за просветление
Спасибо за Primary key. интересные мысли, рассуждения
Большое спасибо за вашу работу. Отличное видео, очень полезный материал!
Спасибо!
Очень качественный материал 👍 спасибо
Ржу нимагу! "Но вот на практике нифига, нифига!" ))
Классно делаешь ролики, много информации и весело! Продолжай в том же духе! :D
Сначала накачал с трекеров терабайты обучащих курсов от инфоцыган теперь позатер их и смотрю ваши ролики. КПД намного выше. Большое спасибо.
👍Спасибо большое за видео. Для себя узнал несколько полезных штучек! Алексей, ты крут!✌😁
Спасибо, было очень интересно и полезно!
Спасибо, очень информативно!)
Отлично рассказан материал, коммент для активности.
Я только недавно начал изучать PostgreSQL, но некоторые моменты из видео заставили более внимательно относиться к структуре БД.
Спасибо большое! Было очень интересно и познавательно, хоть я и мобильный разработчик)
Доступный и подробный разбор вариантов первичных ключей, спасибо за информацию! Наверное нет смысла спорить о применении в первичных ключах int или даже smallint, потому что если такая надобность будет, то разработчик это увидит и применит. А кто-то посчитает что необходимости применения 2-х или 4-х байтового числового первичного ключа не случается никогда.
Я знаю примерно три случая, когда можно использовать small int в качестве первичного ключа, и во всех трёх случаях есть решение в виде естественного аналога: это списки валют, стран и языков. На все три есть ISO с буквенными кодами, и такие коды будут сильно удобнее, потому что их после минимальной тренировки может читать человек. Не то, чтобы я утверждаю, что small int категорически не нужен, просто вспонилось несколько частных случаев.
Спасибо! Очень полезно!
Спасибо за видео!
У меня тоже была как проблема с инкрементом sequence, когда я прям на горячем проде с 150k rpc в секунду добавил строку вручную с явным указанием id.
И как посыпались ошибки! Ух... Хорошо быстро поправил sequence номер.
Спасибо, много нового узнал.
Это я люблю, спасибо!
Благодарю!
Спасибо за информацию
Классный первичный ключ - сотовый телефон
Только у пользователя может быть несколько телефонов, ну и телефон можно потерять.
На мой взгляд - Естественные ключи использовать крайне ненадежно.
Вы должны быть уверены, что естественный ключ уникален в рамках проекта, концов которой не видно. (Подразумевается что вы работаете в проекте, а не пришлый наемник для решения одной задачи)
Префиксы в начале - это реинкарнация Венгерской нотации от MS 😃
Один телефон может быть главным, остальные будут сохранены дополнительно (если нужно их сохранять). Тут больший вопрос по смене телефона, если он PK, то надо будет менять потенциально много записей в разных таблицах, что может быть тяжело. Поэтому пример с телефоном может быть не лучший, да, но мне важнее было показать суть.
Первичные ключи в маленьких табличках часто бывают внешними ключами в больших. И вот там можно много сэкономить.
Частный случай префиксных ключей - это номера паспортов и других подобных документов. Они содержат серию и номер. Серия назначена по территориальному принципу, а номер - это просто счётчик. То есть, каждому актору, имеющему право генерировать первичный ключ, присваиватеся свой префикс, а он внутри себя следит за простым счётчиком. Причём, счётчик персистится с помощью write ahead log: каждый новый паспорт заносится в журнал, и ему присваивается номер на единичку больше от предыдущего занесённого. Ничто не ново под Луной, как говорится)
Классные видосы для гиков у тебя. Я подписан
Спасибооо!
Алексей, респект за контент, а когда будет стрим как на новый год?очень душевно было
Спасибо за контент! А я даже не думал что такие способы есть. На мой взгляд id должен быть наподобии штрих-кода, но чтоб информация там была зашифрована для стороннего пользователя.
Круто :)
Главный недостаток естественного ключа заключается в том что как только на запись с таким ключом появляется ссылка из другой таблицы, то менять этот ключ придётся как в самой таблице, так и во всех таблицах где на запись есть ссылки. Причём делать это придётся в одной транзакции с отложеной проверкой целостности. А ошибиться пользователь может очень легко и ошибочно вбитый номер телефона или паспорта который оказался ключом может вылиться в ряд неприятностей. Поэтому если у вас на таблицу есть ссылки, то очень хорошо подумайте прежде чем делать в этой таблице естественный ключ.
on update cascade 😉
Вцелом согласен, но тут стоит ещё заметить, что номер телефона, номер паспорта, мыло, номер аськи - это всё примеры неудачного естественного ключа, как раз потому, что они могут меняться. Примеры более удачных ключей - это налоговые номера (ИНН, TIN, NIF и др.) и номера социального стразования (СНИЛС, SSN и др.), так как они назначаются один раз и на всю жизнь.
@@andreybogdanov3 спасибо, я что то забыл про такую возможность
@@vryaboshapko в таких ключах есть ещё одна проблема. Это опечатки, а ключ уникальный. И вот оператор вводит, например СНИЛС или номер серию паспорта, если это составной естественный ключ. И делает там опечатку в одной цифре. А в другую организацию приходит человек именно с таким номером, например паспорта. И в той организации ввести его данные не могут и разобраться без помощи разработчиков тоже не могут, потому что опечатку сделала другая организация. В итоге в базе данные не правильные и ввести правильные нельзя. В общем использовать естественные ключи можно, но как по мне с таким количеством нюансов - ну его...
@@user-vz3uy3hh2q для этого в СНИЛС и ИНН зашита проверка целостности. Грубо говоря, если хитро сложить первые цифры, получится последняя (точные алгоритмы публичны и легко гуглятся). Такая же, кстати, есть для номеров баноковских карт, но это не относится к теме естественных ключей). Плюс есть публичные базы данных, по которым можно провалидировать, например, что номер соответствует ФИО или дате рождения. А номер паспорта точно нельзя использовать как естественный ключ (даже как часть составного) по той же причине, что и номер телефона: он меняется. Это уникальный номер документа, а не человека.
Для тех кто не знал, количество номеров ограничено. Операторы очень часто перепродают номера, которыми давно не пользовались. Така ситуация буквально с моим номером произошла. Год не пользовались симкой, не пополнялся баланс и у меня её номер забрали и отдали другому человеку
Перепродажа номеров - это скорее не от ограниченности номерного пространства, а от экономии. В России телефонный номер состоит из 10 цифр, это 10 миллиардов вариантов, это больше, чем людей на земле. Даже если взять, что у мобильных номеров первая цифра всегда 9, всё равно остаётся 1 миллиард номеров, это больше, чем по 7 номеров на каждого жителя страны. Но расширение номерного пространства стоит денег (нужно «купить» ещё один префикс), так что логично использовать номера отключённых абонентов.
По примеру с естественным ключом в виде номера телефона: - очень удобно, особенно когда пользователь хочет поменять номер телефона. Т.е. что проще, посмотреть по номеру телефона id и далее делать все тоже самое по id или при смене телефона иметь ад по сохранению целостности данных? Проблема в том, что зачастую многие естественные ключи не являются абсолютно константными и это создает гораздо большую проблему, чем та польза, о которой говориться. P.S. да, я читал статью про IDотов, к сожалению не могу придумать каламбур про Естественно-отов =)
Если phone_num PK, то чел. уже не сможет его поменять. PK -- это не только UNIQUE NOT NULL, но ещё и read-only. Всё же не нужно юзать phone_num в качестве PK. Это сущность/запись клиент-человек. Даже здравый смысл подсказывает нам, что нельзя его отождествлять/идентифицировать/привязывать к номеру телефона.
Хороший материал, которого всегда не хватает. Кстати, а какую вы тему используете для psql? Вижу, что у вас есть автодополнения и подсветка.
Это pgcli
Приветствую! Спасибо за видос, очень актуально и полезно. Интересно ваше мнение по вопросу: где удобнее всего и эффективнее разрабатывать схему БД? В кансоле сразу, или может в pgAdmin, а может по старинке на листочке схему рисовать?)
Для проекта, когда думаю о данных, сущности рисую иногда сначала на бумаге, чтобы было наглядно. А создавать таблицы уже где угодно. Миграциями как правило, джанговыми или алембик
Сразу лайк!
спасибо!
12:50 - при этом надо понимать, что естественный первичный ключ для справочника тех же пользователей - это та еще мина замедленного действия (помимо потребности хранить длиннющий UID или 11 знаков номера телефона во всех связанных таблицах, где могут быть сотни миллионов записей). Из того же примера в видео: вот пользователь деактивировал сим-карту и мобильный оператор продал этот номер спустя время новому физ.лицу :) Логика сломается уже на этапе регистрации в приложении где-то на бэкенде при обращении к базе. Про момент защиты персональных данных уже в ролике озвучено - тут сразу получается не вариант с естественным первичным ключом
23:00 как ни странно иногда вставка уидов может быть быстрее чем вставка в условный bigint. Особенно если база уже большая и не новая, по той же как раз причине, что вы и описали.
При очень интенсивной вставке, если вставка идёт одновременно из множества сессий, то возможны проблемы за конкурентный доступ последней страницы в которую данные льются, а при уидах вставка происходит в рандомные страницы в разных местах индекса и сессии друг другу не мешают)
Вопрос не в вставке, а в последующем использовании. Чем тяжелее ключ, тем тяжелее join .
При интенсивной вставке в таблицу где pk - uuid, будет происходить очень частая и тяжёлая перестройка индекса, из-за этого как раз и может происходить существенная просадка по производительности.
не досмотрел еще, и не знаю подняли ли эту тему, но хочу сказать, что правильные первичные ключи важны для производительности некоторых кейсов пагинации (я говорю про то, что зачастую правильный первичный ключ - это единственный способ сделать правильную пагинацию без использования медленного оффсета)
Очень неплохо бы разобрать тему uuid6 в сторону ускорения до uuid7 и 8
"Индекс - это отсортированная структура данных" - это справедливо для b-tree, но есть ведь индекс, основанный на хэш-мапе
Алексей, а как ты настроил code-completion при работе с psql в терминале?
pgcli
Капец ты гений какой то)
Алексей, подскажите пожалуйста, насколько будет эффективен индекс для поля, ну допустим varchar(300)?
Да просто потестируйте сами. Сгенерите данных, сколько у вас будет в табличке, сделайте analyze, чтобы обновилась статистика, и сравните выборку без индекса и с индексом. Индекс - не гарантия эффективного выполнения запроса, он даже не обязательно будет использоваться в конкретном запросе, это как планировщик решит.
Про использование identity column было очень интересно. Не был в курсе подобной опции. Впрочем, при грамотном использовании serial не доставит никаких проблем. Достаточно целиком отдать генерацию id на откуп базы данных
Круто!
А про индексы планируется видео?
возможно:)
Пример с телефоном очень показательный. Есть у нас история действий пользователей с неким номером телефона. Казалось бы удобно. Но люди бывают что меняют номера телефонов. и если пользователь сменит свой телефон он лишиться всей своей истории.
По поводу always generate. А что если нам требуется восстановить таблицу из бэкапа и при этом в ней есть пропуски(удаленные записи)?
крутая картинка. кач хорош
Алексей, а что по поводу скорости поиска по uuid ключам по сравнению с числовым типом? Кажется сравнение строк должно сильно ухудшить этот показатель. Или для uuid используется какое-то хитрое быстрое сравнение?
Postgresql автоматически создает индекс для primary key. Поиск по индексированному полю работает быстро.
UUID это не строки, а 128 бит и нужно сравнивать 128 бит, что достаточно быстро. Но int будет занимать меньше месте на диске и если это внешний ключ то по числу поиск будет чуть более эффективнее, потому что меньше нужно держать в памяти или читать с диска. Просто индекс будет компактнее
@@programisli пхах, какраз когда прочитал 128 бит, в видосе на 20:13 прозвучало "весит 128 бит"
128 бит - это 16 байт. То есть, сравнение двух UUID-ов занимает столько же времени, сколько сравнение двух строк из 16 символов (если речь не про юникод, конечно). Но стандартоне текстовое представление UUID-а (123e4567-e89b-12d3-a456-426614174000) - это 36 байт, то есть, сравнение двух строковых представлений UUID-ов занимает больше времени, чем сравнение двух честных UUID-ов. Кроме того, UUID в памяти может быть представлен не как набор байт, а, например, как два лонга (64-битные целые), и тогда сравнене будет ещё быстрее, потому что современные 64-битные процессоры могу сравнивать 64-битные целые за один такт.
По скорости инкримент будет в десятки раз быстрее, поэтому делают два ключа, id и uuid, один для внутренних релейшенов, другой для внешки
Полезное видео, спасибо! А где можно найти параметр, отвечающий за такую зеленую подсветку кода?
Спасибо! Это pgcli
Как можно проверить, что uuid_v6 (ulid, objectId) в качестве primary_key работает быстрее на больших объемах данных, чем uuid v4? Какой тест тут лучше применить?
Для записи приходит в голову что-то типа "генерируем 10ккк uuidV4, затем в другой таблице 10ккк uuidV6, сравниваем время". А для чтения это как лучше проверить?
Мысль про ключи естественные ок, но пример с номером телефона плох(опасен). Клиент может захотеть сменить номер телефона и вот тут придётся менять ваш PK, что выльется в проблемы и боль миграций.
а если использовать "generated always as identity" то не будет проблем при импорте? Например если одна запись удалена просто заново сгенерировать не вариант.
А есть видео где рассказывается про настройку терминала? Что бы так же дополнение запросов было? Или же это именно дополнение из консоли постгресс ?
Прикольное худи Lacoste. Подскажи, модель или серийник)
А что если префиксную часть сделать модифицируемой по длине? Тогда мы сможем выбирать приоритет на скорость записи или скорость чтения из БД соответственно по скорости формирования и чтения индекса
До этого видео относился к UUID как к безумной глупости. Побежал добавлять это дело к себе в петпроект
UUID v6 выглядит перспективно, но я бы вообще пошел дальше и использовал nanoTime, а для формирования рандомной части оставил последние 11 байт (12 символов).
Будет ли видео про обновление питона до 3.12?
Будет
👏
9:30 т.е. create view с join и работать так же с телефоном но с view нет?
не понял вопрос
Я извиняюсь, только включил ролик и увидел прикольный вывод в консоли команд, это что за утилита?
pgcli , увидел дальше в видео
pgcli
Да, она. На питоне написана, немного багнутая, отправлял туда PR)
А почему у вас PSQL такой красывый?
На первой минуте. Или это для маков эксклюзив?
pgcli
21:01 - чтобы ориентироваться по времени как вариант можно использовать uuid v7
как в ПГ при импорте дампа сделать ремап имени схемы по аналогии с oracle remap_schema? =(
Как в постгре работают индексы под капотом уже был видос? :)
4:08 а потом пользователь захочет сменить почту) и полетел наш первичный ключ во всех связных таблцах. Первичный ключ лучше всегда делать искусственным.
Конечно это просто пример, хотя не вижу проблем с заменой email, это же не автоинкремент и поле изменять можно. Будут проблемы с обновлением связей - да, но решаемо. Никогда не говори всегда. Возможно email был не самым лучшим примером, но вот например у тебя есть таблица стран и у стран есть Abbreviation - Name со значениями RU - Россия, US - США. Не нужен тут искусственный ключ, если первичный ключ на Abbreviation будет уникальным, и гарантирует уникальность Abreviation.
@@programisliтак вот чтобы потом не думать как исправлять, надо тупо делать искусственный ключ. По этой же причине надо не думать и делать сразу микросервисную архетиктуру, потому что сделав монолит через года можно сильно пожалеть.Сколько таких случае когда куда не глянь а все монолит свой пилят на сервисы? Всетоки есть практики - железны, которые уже написаны кровью
@@programisli а потом в один прекрасный момент у страны всеже поменяется Abbreviation-Name) Или изменится вид с двух значного на трехзначный.
Использовать всегда только один подход это упрощение жизни, упускаются всегда какие-то случаи. Как писал в соседнем треде, телефон сейчас это почти всегда обязательное к заполнению и уникальное поле, однозначно идентифицирующее клиента - как бы вы ни считали это идиотизмом. И даже вопросы смены решаются, удивительно.
@@t0digital все решается, только нафига перебирать все таблицы и заменять связи? Когда есть скажем так профессиональные подходы, я имею ввиду некое решение сбалансированное которые не подведет никогда как показывает практика. И чего кривляться когда оно надежное? Это как многие вещи в разработке стали стандартами дефакто, например докер. Чтобы ты не делал всегда все делай в контейнерах - простой рецепт решающий все будущие проблемы. Или микросервисы - никогда не делай монолиты иначе рано или поздно обожжешься на масштабируемости.
Просто для заметки:
Если x = "Иногда" и y = "Всегда" то
y = K * x, при условии К - частота случае "Иногда" и она стремиться к бесконечности )))))
Кайф
Расскажи про timescaledb
Спасибо, послушал с интересом. Единственно не согласен с настойчивой рекомендацией использовать bigint в качестве ПК. Обычного int хватает в 99%, если только вы не собираетесь автоматизировать весь мир. В любом случае нужно понимать на какие объемы проектируется система, и принимать проектные решения исходя из этого.
Еще раз спасибо, хорошая подача материала!
Накладные ресурсы которые уйдут на bigint не сравнятся с болью перелапачивать бд и менять типы с int на bigint
а что делать, если юзер, которую вы определили первичным ключем номер телефона, поменял номер телефона? получается, что возможности в аккаунте на смену номера уже не будет?
Возможность есть, но, конечно, надо тогда везде будет менять ключи во всех таблицах, ссылающихся на юзера. Смена телефона к которому привязан акк это оч редкая операция. Тут вот в комментах кто-то писал, что в ВК решается через запрос в поддержку с паспортом
Для микросервисной архитектуры, где создать общий ID для всех систем проблемно, а обрабатывать одну и ту же сущность надо - это вполне себе рабочий вариант. Широковещательным сообщением по системам разносится требование обновить PK с ON UPDATE CASCADE и должно работать. Плохой, лучше все-таки генерить сквозной ID для всех систем. И не забыть про денормализованные структуры, которая содержит те же данные, но без FK.
23:32 а в чём сложность с WAL в этой модели?
У ulid есть некоторая проблема в том, что инстансы приложения генирующие улиды могут находиться на разных физических машинах с рассинхроном времени, проблему рассинхрона ещё человечество до конца не решило. Поэтому в распределенной системе не факт, что каждый следующий сгенерированный ulid будет лексикографически старше предыдущего.
Разве рассинхрон в несколько миллисекунд это проблема?
@@vladislavstepanov7591 фишка ULID в том, что один ULID больше другого, если он сгенерировался позже на 1мс, чем первый. Но если на разных тачках есть рассинхрон, то польза от ULID'a нивелируется и проще использовать UUID v4
Сделай видево как быстро считать количество всех результатов выборки, с учетом фильтров, в постгресе
Count(*) же
Случайно наткнулся на видео, не лишним было бы упомянуть про вставку батчем и генерацию айдишников на стороне бэка.
Имеете в виду, что вставка пачкой ссылающихся друг на друга записей возможна с айдишниками, которые генерятся не в базе? Об этом есть в видео
@@t0digital Имею ввиду, что бывают случаи, когда генерация айди не эффективна на уровне базы. Например кейс когда нужен высокий перфоманс и применяется вставка батчем.
с таким крупным шрифтом ты очень быстро сломаешь себе глаза! 12 должен быть максимальный.
Шрифт для видео увеличиваю, чтобы было видно всем
Опечатка в назавании ULID v6?
Спасибо, поправил
Говорят mongodb при частых обращениях может занимать место в ОЗУ для более быстрого ответа, наверняка ведь pg не с диска каждый раз читает? Может быть сможет кто-то пояснить?
Конечно, pg не с диска читает каждый раз. Кэш и всякое такое имеется
Когда постгресс запускается, стартует постмастер процесс. Он ждет подключения от клиентов БД. От посмастера также форкаются множество других бэкенд процессов, которые выполняют CRUD операции и разные служебные задачи типа логирования, создания WAL, репликации. Процессы, которые выполняют CRUD, имеют общий доступ к ограниченному сегменту оперативной памяти - shared buffer. Это позволяет процессу брать результаты sql запросов из оперативной памяти, если такой запрос уже был адресован БД. Если в общем буфере результата запроса не найдено, есть шанс, что результат будет найден в кэше ОС ( другой сегмент оперативки). Если нигде ничего не найдено, придется обращаться к файлу БД - это уже IO.
Знаю такой прикол, когда мы делаем UID-ы самостоятельно, которые получаются из витовых склеек из других полей. Не знаю правда зачем.
360*1500= 540к, неплохо))
налоги, комиссии, съемка, монтаж, команда с зарплатами и 31 день работы в месяц - неплохо
Впервые слышу термин "искусственный" в отношении первичного ключа. Устоявшимся является "суррогатный", нет?
возможно, да
Иметь или быть* если я правильно понял, то какая книга имелась ввиду
Хочу чтобы в кадре была красная кружка с лого "D!"
get_random_uuid был добавлен в PostgreSQL 13
Ого, а интересно, как консоль на маке собирает таблицу для оторбражения? Красиво же выглядит, не то, что поплывшие таблицы на символах -- |
А не, тоже плывёт.
Неужто про все это ты узнал с книжки Моргунова?
Нет, у Моргунова об этом не было. Просто тема затронулась и мне с ней было давно интересно разобраться
@@t0digital Молодец, я, к примеру, занимаюсь Postgresом 3-4 месяца, но такой углубленный материал на эту тему еще не находил.
Натуральные первичные ключи это велосипед из костылей.
Это грабли, подложенные если не себе, то следующему программисту/админу. Если не с уникальностью, то с производительностью.
В общем, натуральные ключи могут использоваться, но только в исключительных случаях, по уважительным причинам.
Таблица стран. Обоснуете, почему название страны нельзя сделать первичным ключом и почему это плохо повлияет на производительность?
@@t0digital Первичный ключ по строке - глупость.
Это намеренное снижение производительности и раздувание размера БД (т.к. это поле копируется во все связанные таблицы).
Это нарушение сложившихся практик без уважительных причин.
Ну и весь ворох оговорок, которые вы и сами озвучивали.
@@t0digital Кроме того. Страна может сменить название и из-за такого дизайна БД, нам придется менять все ключи в таблицах.
Страна также может распасться и объединиться с другой (upd: что, впрочем, в любом случае потребует коррекции более чем одной таблицы).
@@semibiotic размер строки не обязательно больше размера UUID'а, например
Случай распада страны никак не осложняется ключом с названием страны, его надо обслуживать и в случае искусственного ключа