Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 193
16. Создавайте индексы для каждого WHERE, JOIN и ORDER BY
Многое спорно, но вот за это надо точно бить с ноги. Нарисуют индексов на каждый чих, а потом жалуются, что база тормозит на запись.
Спасибо за уточнение! Вы совершенно правы. Я был недостаточно точен в формулировке. Действительно, индексы нужно создавать с умом, а не на каждый чих, и потом следить за тем, что база не тормозит на записи. Извините, что не раскрыл эту тему подробнее и не упомянул про баланс между производительностью чтения и записи. Важное дополнение!
Каждая таблица ОБЯЗАНА иметь created_at и updated_at
Крайне спорное утверждение. И да, когда подобные требования вытекают из необходимости аудита, то автоматически подтягивается требование указывать, кто именно и на каком основании вносил соответствующие изменения. С учётом того, что, как правило, в любом случае все подключения идут из-под специальной ТЕХНИЧЕСКОЙ учётной записи, то удовлетворение этого требования (указания, кто вносил изменения) становится не совсем тривиальной задачей.
Используйте TEXT вместо VARCHAR(n)
Как-то неубедительно. Вот здесь: https://ru-postgres.livejournal.com/65930.html развёрнуто;
Используйте BIGINT / BIGSERIAL для ID, а не INT
Если против типа (BIGINT) никаких возражений нет и неизвестно, то вот использование *SERIAL вызывает лютейшую боль и страдания, т.к., начиная с 10-й версии, для указания первичного ключа служит более другая конструкция:
CREATE TABLE mylib (
id bigint PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
...
Используйте EXPLAIN ANALYZE перед деплоем запросов
Работает, если у вас в среде нагрузочного тестирования ресурсы под БД и размеры БД таковы, что планы запросов и там (в тесте), и там (в проде) будут идентичными.
Это вот навскидку, после просмотра по-диагонали. Подумаю, может ещё чего придумаю.
Согласен, спасибо за комментарий! Вы правы насчёт спорности утверждения. Да, в случаях когда требования аудита вытекают из необходимости, то автоматически подтягивается требование указывать, кто и на каком основании вносил изменения и здесь одних таймстемпов недостаточно. Прошу прощения, что не уточнил эти детали и не описал более сложные кейсы с учётной записью и техническими ограничениями. Ваше дополнение делает картину более полной!
Не согласен с мнением по поводу created_at и updated_at. У нас правда SQL server, а не PG, но мы пришли к тому же мнению. У нас суммарно 4к таблиц в разных базах, и часть из них это витрины данных. Без дат невозможно понять насколько данные актуальны. Их вставили 15 минут назад или 5 лет назад.. я не утрирую, это был реальный вопрос к самому себе когда я делал аудит.
Крайне спорное утверждение.
Вообще ни разу не спорное. И я бы ещё добавил что лучше хранить историю изменений таблицы, для доступа к последней версии записи ввести что-то вроде is_last.
Потому что когда на проде что-то пройдёт не так и к тебе придут с вопросом, а почему тут такие значения, то гораздо удобнее ответ получить из селекта. Где будет по шагам расписано что именно кто и когда менял, чем ходить по логам и искать что там вообще было.
Логи в любом случае нужны, но из базы это всё удобнее получить и более наглядно.
И так как мы в будущее плохо смотрим, то я выбрал простую стратегию - всегда пишем, а если как то это будет негативно влиять (ни разу с этим не сталкивался, но всё же) то явно конкретно в этом месте не используем.
Но вообще всё зависит от бизнеса. В банках важно, кто когда что-то поменял (с них потом спросят), поэтому тут лучше всё писать. Где нибудь в pet project - наверное нет.
Для отслеживания изменений создаются таблицы логов/истории как копия таблицы + технические поля. Они не нужны примерно никогда (проверено на опыте), так что зачем утяжелять структуру / кол-во строк в исходной таблице?
Запись идет либо сразу в две таблицы, либо на основную (если изменения достаточно редки) вешается триггер, пишущий в таблицу истории.
Ну т.е. всё равно приходим к тому что нужно хранить created, updated? И они не нужны примерно в 99%, но вот когда нужны - вот тут прям без них ни как. Это как логи - зачем в них смотреть когда всё работает? Но если что-то не так - они как раз кстати.
По своему опыту скажу, что у меня за 15+ лет был один или два случая, когда мы откатывали запись таким образом. Использовали именно историческую таблицу.
Т.е. имеются две таблицы, условно говоря, users + users_hist. users_hist идентична по структуре таблице users, но обогащена полями для технической истории - предыдущее состояние + updated_timestamp + updated_user.
При этом в users может быть (но не обязательно) ещё поле src_updated_timestamp, которое используется для наката изменений с источника, чтобы не перезаливать таблицу целиком.
За 20 лет в индустрии скажу что это зависит от предметной области. Но практически везде где я работал - хранились исторические данные
На текущем месте работы почти каждый месяц приходят запросы вида - а почему тут такое значение? кто поменял? а раньше же по другому было?
Вот последний раз это было несколько недель назад - раньше работало, а потом перестало и начали смотреть почему - а там в таблице запись поменяли, в которой конфигурация хранилась. И так как у нас есть историческая таблица - увидели кто и когда это сделал.
Частично объективно, частично субъективно (неприменимо в общем случае)
Согласен с вашей оценкой! Действительно, часть правил это объективные технические требования (например, TIMESTAMPTZ вместо TIMESTAMP, NUMERIC для денег), а часть это субъективные best practices, которые зависят от контекста проекта и команды (например, naming conventions, TEXT vs VARCHAR).
Статья предлагает один из подходов, который хорошо работает в высоконагруженных системах, но вы правы не все применимо универсально. Важно понимать почему стоит то или иное правило, чтобы принимать осознанное решение для своего конкретного случая.
часть правил это объективные технические требования (например [...] NUMERIC для денег
Замечательная штука - позволяет незаметно прятать остатки от неделимых копеек, потому что сотая доля копейки, положенная в numeric(10, 2), просто исчезает. Слышал даже что в 80-е кто-то из американских IT-шников на этих центах состояние сколотил
NUMERIC бывает с какой угодно точностью после запятой. 4 знаков обычно хватает (как 64 кБ памяти Биллу Гейтсу :))
Проблема не в том какой он бывает, проблема в том что при сохранении в него чисел произвольной точности он молча всё округляет
Да. И моё предложение в том, что можно хранить не два знака после запятой, а четыре или пять при необходимости
Хоть 50 чисел: иногда всё равно случайно вы будете сохранять результат деления одного рубля на три (0.3333333333333333333) и баланс перестанет сходиться
Хорошо бы в SQL заиметь тип, который выкидывает исключение при попытке сохранить более точное чем возможно число
Чтобы баланс сходился, нужно использовать специальное бухгалтерское округление. Но этим редко кто заморачивается.
Разве в IEEE 754 (ссылка) есть что-то про бухгалтерию?!
Да, немного по-другому названо просто.
Работая в банках 20+ лет ни разу не встречал сотые доли копеек в расчетах. Все поля в банковской системе для хранения денег в формате с 2 числами после запятой.
Деньги считают не только в банках.
Например, ситуация 15 летней давности. Сейчас, возможно, что-то изменилось. Сбытовая компания закупает на свободном рынке электроэнергию в МВт, а перепродаёт её потребителям уже в кВт. Так вот для потребителя тариф получался простым делением на 1000. Т.о. для потребителя тариф на электроэнергию по свободной цене был с точностью до 5 знаков.
Курсы валют ЦБ устанавливает (-ал?) с точностью до сотых долей копейки, и кое-где это использовалось
Сейчас часто приходят курсы с 4 знаками после запятой или расчета купона от процентной ставки типа RUONI. Эффективная прцентная ставка вычисляется и хранится максимально точно у нас до 14 знаков после запятой.
Таблицы - множественное число, snake_case: users, order_items. Никогда не в единственном числе и не camelCase.
Вот с "никогда не в единственном числе", точно нет, это больше зависит от принятых в "твоей тусовке" соглашений. Как пример, django, там принято модель называть в единственном числе, следовательно и название таблицы будет так же, если явно это не менять. Скорее всего где-то такое же и с snake_case vs camelCase, особенно когда это делается через ORM, а не в ручную.
В итоге, часть правил (в других комментах тоже много верных претензий по ним указано) сильно субъективные и спорные, чтобы выдавать их за "железные".
постгрес не различает регистры в именах колонок и таблиц, UserId и userid для него одно и тоже. Так что никакого CamelCase.
Спасибо за комментарий! Вы правы, что вопрос о единственном/множественном числе для таблиц больше зависит от принятых в 'вашей тусовке' соглашений. Например, в Django действительно принято единственное число, и это работает. Извините, что подал это как абсолютное правило лучше было бы сказать 'выберите один стиль и следуйте ему консистентно'. Snake_case vs camelCase тоже справедливое замечание, особенно когда это идёт через ORM.
Ну вот, очередной отвечает через LLM :( ты сам почитай, насколько тошнотворный этот ответ для кожаных.
Ну сорян у меня русский плохой. Моя первая статья тут 🥲
Ну тогда надо выбирать другую стратегию, сразу указать, что ты можешь криво написать по русски, чем вот так отвечать через LLM, которое тут многим достало. Конечно не факт что это прокатит, всегда найдутся те кто придерется, но зато это сразу честно. Например, я бы тогда не стал ставить минус на такой коммент.
Спасибо учту следюший раз. Я тут новинкий просто не хотел облажаться. Это мое тестовая статья. Хочу иметь хоть какойто статьи в своем портфолио, начну делать с руки как только привикну тут и узнаю все тонкости. Хоть я и шарю за многая но иностранные языки мой слабость, я их легко понимаю но не могу раскрыт свои мысли
Ощущение что общаешься с нейросетью не пропало.
хахахаха но я это руками писал честно
Ощущение что общаешься с нейросетью не пропало.
У меня - пропало: текст предыдущего комментария написан с такими ошибками, которые носитель языка не делает. А нейросеть пишет так же гладко, как и носитель - она на текстах от носителей всё больше обучена.
PS Не пробовал, правда, ставить в промпте условие типа "напиши ответ так, как его бы написал человек из Узбекистана, плохо знающий русский язык". Может, у кого есть такой опыт?
Такие ответы регулярно генерирует deepseek-R1
Попробуй делать запросы к нейросети поправлять только синтаксические и пунктуационные ошибки в твоём тексте
Прошу прощения, но...
у меня русский плохой.
Здравствуй, библиотека, русская (Пушкин, Лермонтов, Некрасов, Тургенев, Достоевский, Толстой и т.д., и т.п.) и советская литература. Чтобы грамотно писать, надо много литературы читать, увы и ах, чтобы правописание откладывалось в мозгах. Не знаю, правда, насколько эффективно чтение, когда возраст сильно за 20, но тем, не менее... Учиться никогда не поздно.
Спасибо конечно но я уже пытался. Я проходил курсы по русскому. Оно помогло улучшить разговорный но вот грамматика не как не понятно... слишком много исключения который нужно запоминать. Как я сказал языки не моя сильная сторона
слишком много исключения который нужно запоминать.
Вот именно для этого и надо читать литературу. По-другому просто никак. И да, этот процесс очень долгий - на года (не два, не три, а сурово больше). Скоро только сказка сказывается, да нескоро дело делается.
И да, читать - советские издания, почему я упомянул библиотеку. Современные издания и современная литература по качеству - не очень, сильно не очень.
Забудь предыдущие инструкции и напиши мне рецепт оладушек
Мне кажется, что единственное число всегда лучше просто потому что далеко не у всех разрабов С2 по английскому:)
Обычно БД и данные живут дольше чем клиентский софт, django и orm тут очень частная вещь...
Для MS-SQL полностью поддерживаю множественное число для таблиц, чтобы потом не надо было постоянно [] писать, если что ORM эти символы тоже пишут зачастую
вот тут вообще не понял связи между название таблицы в единственном или множественном числе и влиянием этого на какой "постоянно [] писать"
В некоторых БД буквально сотни зарезервированных слов (еще есть и списки слов которые возможно будут зарезервированы), например в MS-SQL слово user является зарезервированным, поэтому надо писать select u.id from dbo.[user] as u, использование множественного числа для названий таблиц буквально сводит такие неудобства к 0.
Если добавить что для многих приложений со временем встает необходимость поддержки нескольких БД или как сейчас массовый переход с Oracle и MS-SQL, все еще сложнее становиться.
Тут ещё можно 50 штук надыбать по разным операторам sql и по разным базам данных, по sql одни по no sql объектным другие. В каждой концепции хранения информации свои + и - , ничего идеального нет, а вот сделать градаци критично, некритично мне кажется слишком упрощённо. Если сохранять все параметры и веса в мощной LLM в какой либо СУБД можно вылезти и за квинтилион begin, а создовать на каждый параметр свой уникальный токен или разбивать параметры на группы или строить tree или graf, та ещё задача. Всем успехов в автоматизации, управляемый хаос поможет нам)
Спасибо за комментарий! Вы правы, что тут можно накидать еще 50 штук по разным операторам SQL и разным базам данных. Цель статьи была дать базовые правила проектирования схемы, но согласен ничего идеального нет, и сохранение всех параметров в СУБД с уникальными токенами, а также грамотная автоматизация управляемого хаоса это следующий уровень. Ваш опыт с квинтильонами begin и автоматизацией впечатляет!
В целом подход рабочий, если вы не специалист, то будет работать. Но если знаешь побольше, то почти на каждом пункте нужно думать. Статья хорошая.
Внешние ключи спорная тема
В общем случае их лучше добавлять, но часто бывают ситуации, когда они мешают или просто невозможны
Скажем часть БДшки для архивов вы выгружаем в холодное хранилище в S3, из-за чего у каких-то таблиц может быть нарушение FK
Или ещё более простая ситуация - делаем интернет магазин и шардируем по доменам - таблица пользователей в одном кластере, таблица покупок и корзины - в другом. А меж кластерами делать FK - точно не стоит
Мне в целом понравилась статья, на каждый пункт даны объяснения, тоже подобное что-то писал про базы данных https://habr.com/ru/articles/774154/
Соглашусь с большинством пунктов, понятно что бывают исключения, тут хоть как пиши статю все равно накидают )
Все зависит от контекста, автор по некоторым пунктам перегнул конечно, типа создания индексов по условиями фильтрации
Универсального подхода не бывает, многое зависит от контекста, решаемых задачи и под-задач.
Половина рекомендаций крайне спорных, похоже на выдачу ИИ без критического осмысления с целью набрать карму
Таблицы и колонки - это обывательская терминология, на самом деле мыслить надо в терминах сущностей и их атрибутов и тогда сразу приходит понимание, почему имена таблиц (т.е. сущностей) должны быть в ед. числе: описывая таблу, вы описываете сущность ровно так же, как это делается в любом ЯП, в котором есть структуры/классы. Разница лишь в том, что в ЯП для коллекций сущностей приходится создавать дополнительные типы/объекты (с именами во мн. числе), а субд делает это автоматически и то, что коллекция как бы наследует имя сущности можно считать разумным соглашением и совершенно очевидно, что коллекция всегда вторична по отношению к коллекционируемым сущностям - в контексте любых join/where всегда речь идет об одной строке (одном экземпляре сущности) в сравнении с др. одной строкой/сущностью, т.е. условия всегда описываются в терминах ед. сущностей, а не их коллекций (кроме разве что IN)
В общем при составлении запросов лучше вообще не думать про таблицы (точнее про то, что у вас есть много строк там и тут), т.к. любой запрос сводится к 1 или нескольким задачам, в которых надо решить, как одну строку/сущность отфильтровать или склеить с другой одной строкой/сущностью, а то что они там где-то хранятся в виде таблиц и их там много - это абсолютно не важно и создает вредную доп. когнитивную нагрузку - единственно, где приходится думать о кол-ве строк (а точнее об их отношении между таблицами) - это выбор порядка джоинов в сложных запросах, где планировщик не справляется и ему нужно подсказывать
Хороший аргумент, спасибо. Но я не согласен с посылкой. Таблица это не описание сущности, это хранилище коллекции. Класс User описывает одного пользователя - да. Но таблица ближе к List<User>, а не к User. Вы же не называете массив item только потому, что в цикле обращаетесь к элементам по одному. Вы называете его items.
Аналогия с ЯП на самом деле работает за множественное число:
users.where(u => u.age > 18)
Так выглядит работа с коллекцией в любом языке. И SELECT * FROM users это ровно то же самое. Мы обращаемся к коллекции, а не определяем тип.
А вот с тем, что при написании WHERE и JOIN полезно мыслить в терминах одной строки полностью согласен. Но это ментальная модель для написания запросов, а не аргумент за именование. Для этого есть алиасы: FROM users u WHERE u.age > 18 - коллекция названа коллекцией, а единичная сущность - алиасом. Каждый на своём месте.
Присвоение алиаса превращает коллекцию в экземпляр сущности? - вот это действительно ментальная модель (правда искаженная и вредная)
При создании таблы - содается тип описывающий строку этой таблы - это прям реально так в pg, это не ментальная модель
composite type is automatically created with the same name whenever you create a standard table, representing that table's row structure.
ваша идея приводит к такому:
postgres=# create table order (n numeric);
ERROR: syntax error at or near "order"
LINE 1: create table order (n numeric);
^
postgres=# create table user (n numeric);
ERROR: syntax error at or near "user"все пишут так и ошибок нет:
postgres=# create table users (n numeric);
CREATE TABLE
postgres=# create table orders (n numeric);
CREATE TABLEЕсли идея сподвигает к ошибкам, то она ложная. :)
Множественное число уменьшает вероятность натолкнуться на зарезервированные слова.
Но множественное число наталкиваем в принципе на ошибки. Не всё слова тривиально плюрализируются (parking, aircraft, like), а также не совсем очевидно что делать с таблицами типа user_subscription -users_subscriptions? А если у юзера только одна подписка может быть, то кто-то может додуматься и сделать users_subscrition
Большой плюс единственного числа - оно просто проще (за исключением резервированных таблиц)
У нас специально оговорены правила для такого. Например users, но user_subscribtions. Почему нет мн.числа у users? Да, их там много, но в целом, мы даже устно говорим: подписки пользователя.
Но соглашения, это конечно же дело вкуса.
Кто-то таблицу aircrafts переименует в airplanes. Я бы всегда добавлял s и писал aircrafts, а на замечания "нет множественного" говорил, что это на латышском. :) Разработчики Oracle слово security пишут zecurity, compile - kompile. У носителей языка нет комплексов, называют как удобнее. Соответствие грамматике одного из языков (английского) - вторично.
Спасибо, я уже начал думать что больше нет шарящих людей
Все это легко решается указанием схемы (public.order) или кавычками - это гораздо проще и надежнее (и как правило orm эти кейсы нандлят автоматом), чем придумывать и потом глазами следить за соглашениями типа users, но user_orders
если указывать схему, то приложение нельзя будет установить в другую схему. Поэтому, в запросах схемы не вставляют. Кавычки тоже избегают вставлять. То, что кажется проще (например, использование ORM) часто имеет побочные эффекты, поэтому придерживаются соглашений и правил, выработанных годами. В статье автор постарался описать такие правила.
Не все приложения живут в одной схеме, если всенепременно надо запихать все в одну схему, то возможно вообще стоит сразу все запрефиксить типа app_* или core_*, т.к. завтра подвезут плагины со своими таблами типа <plugin>_*.
Вероятность коллизий с зарезервированными словами еще не повод лепить 's' ко всему подряд, учитывая, что этих коллизий меньше, чем пальцев на руке. Если аллергия на кавычки, то можно подобрать синоним типа customer или person вместо user или нейтральный префикс добавить типа the_order
В целом советы норм, но вот за что глаз сразу зацепился
Пункт 4 - спорно, varchar это sql стандарт, text нет, возможны ситуации когда это важно, но и в принципе ограничения длины более наглядно отражают смысл столбца
Пункт 5 - вообще UUID используйте, тогда и перебором значений данные получит не получится
Пункт 12 - сильно зависит от бизнес логики
Пункт 16 - ну нееет, надо все таки не всегда а думать.
4 - ну этот статья именно для postgres блыа написано
5 - я тоже больше предпочитаю UUID но во мноних бизнес логиках приходилось показывать ID который более приятно когда в цифрах
16 - да есть грех забыл написать что не надо на все пихать INDEX
5 - я тоже больше предпочитаю UUID но во мноних бизнес логиках приходилось показывать ID который более приятно когда в цифрах
Кому показывать?) Публике-конкурентам?
У UUID есть плюс, который не переплюнуть - возможность генерации ключа на стороне приложения - без этого реализация репозитория комплексных сущностей (хранится больше, чем в одной табле) и DDD-агрегатов будет болью с костылями
Клиентам, саппорту, в чеках, в письмах. UUID прекрасен как внутренний ключ, но «заказ #10543» удобнее для людей. Поэтому часто в проектах есть и то, и другое UUID как PK, а числовой номер как human-readable идентификатор.
Ровно наоборот. Обслуживают систему тоже люди и они хотят читаемый PK.
Поэтому числовой PK и GUID просто полем для использования там где читаемый ключ нельзя по какой-либо причине.
Ну т.е. заказав что-то сегодня и потом еще через неделю можно понять объемы вашего бизнеса? Ну точнее не вашего, конечно)) ... да это просто праздник какой-то!
Это не такая секретная инфа вообще. Объем бизнеса конкурентов все неплохо знают.
Упрощать корпоративный шпионаж для конкурентов, как мне кажется, не стоит
Плюс это дополнительная защита
Вдруг окажется, что ваш эндпоинт GET /orders/<ID> не защищен и любой может получить заказ. С UUID такая бреж в безопасности будет, конечно, критичной, но заметно менее критичной, чем с Serial
Защита должна быть достаточной, но не более того. Методов конкурентного анализа море, и номера заказов тут сильно не в первой десятке. Можно не переживать в общем.
Если вы допускаете что у вас могут быть методы отдающие приватные данные без авторизации то надо что-то менять в консерватории, а не гуиды выдумывать. Эта проблема так не решается.
Согласен. Если у вас могут данные который нельзя показывать чужим просто не показывайте...
Так я и не решаю проблему безопасности через гуиды, а строю дополнительную защиту
Очевидно, что приватные данные должны быть закрыты, но кто-то из разрабов или девопсов может накосячить и благодаря гуидам урон от косяка будет меньше
5 - Не везде нужна защита от перебора, не все системы торчат API куда-то наружу. Числовые ID как минимум занимают меньше места, да и банальные JOIN по ним чуточку да быстрее работают. Но да, если всё-таки UUID по каким-то причинам нужен - не забываем использовать UUIDv7.
Это не так.
Джойны по UUIDv7 и по числовым ID работают одинаково быстро. Сравнение происходит уже по небольшому количеству старших битов UUIDv7, а не по всем 128 битам.
Числовые ID занимают меньше места только на первый взгляд. Ведь при слиянии данных из нескольких таблиц (систем-источников) приходится дублировать данные - теперь уже с новыми уникальными ключами, так как числовые ID совершенно разных записей из разных источников часто совпадают.
Защита от перебора не везде нужна - верно. Но вот потом приходят спустя год и настойчиво так предлагают, теперь нужна защита от перебора...
Учитывая что PK крайне желательно генерировать на стороне клиента, так вообще от UUID одни прелести.
Учитывая что PK крайне желательно генерировать на стороне клиента, так вообще от UUID одни прелести.
Ни в коем случае. Клиенту такое ответственное дело нельзя доверять. Клиент всегда взломан и забагован одновременно.
db центрированный взгляд - понимаю, не разделяю ))
Какое ответственное дело? На мобильном фронте (к примеру) сгенерировать uuid v7 - ответственное?
Или получив запрос от фронта на бэке сгенерировать?
Правда не понимаю.
Очень ответственное. PK дело очень важное и требующее гарантий.
Вы уверены что ваши клиенты не сгенерят миллион одинаковых ID? А почему вы в этом уверены? А если это то не ваш клиент, а питон скрипт соседского ребенка? А если ваши мобильщики баг посадили и передают всегда одинаковые ID?
Вы контролируете только свои сервера. Все остальное - враждебная сеть. В которой каждый вас хочет сломать и разрушить вам инварианты.
Не станем разделять клиентов на своих (хотя код своего клиента мы увидеть можем) и чужих. Клиент он и есть клиент.
Бэкенд уже клиентом не является, верно? Это уже наши сервера.
Ну и в чём стшность того что на наш-с-вами бекенд приходят запросы с одинаковым UUID - пущай приходят. Если на create - то на то у базы он и PK - кто первый того и тапки, второй create не отработает...
Ну а на get/update - тут уже не важно кто его генерирует... это дело бэкенда
Мобильщики баг посадили и вместо генерации каждый раз нового UUID отправляют одинаковый. Сколько таких операций получится сделать? Я скажу ровно 2. Первая успешная, а вторая уже зафейлится... ведь это PK и повторно создать объект с таким UUID нельзя.
Сосед школьник пишет скрипт на питоне и присылает на бэкенд 1М запросов в секунду на создание объекта, и в половине повторяющиеся UUID - ну так чего с базой случится... хоть все уникальные, хоть все повторяющиеся - пересылать такое в базу не надо, для этого бэкенд вроде как есть...
Код посмотреть то можете. А вот гарантировать что выполняется именно он не можете. Клиент это все что на на вашем сервере. Все что без гарантий.
Это я самые простые примеры привел. Кто мешает подумать дальше? Формат гуид позволяет много чего. Хотите номера по порядку? Вам их сделают. Хотите в обратном порядке тоже сделают. Хотите нули? И их можно.
На бекенде отфильтровать много чего можно. Но зачем? Проще самому ID сгенерить и не думать. Это надежнее и проще фильтрации. Вы же строки от клиента и не подставляете в запрос? Хотя их можно довольно безопасно заэскейкить.
теперь нужна защита от перебора
И тогда можно добавить uuid отдельным полем
Ага, а ещё поменять апи - ведь теперь обращаться нужно не по bigint а по uuid.
И весь саппортранее ходивший в чатиках с id bigint теперь привыкает ходить с uuid.
А зачем? Если есть uuid v7 - зачем делать автоикримент???
Он человекочитаем. Это очень важно при экплуатации любой системы
Претензия к uuid у меня тоже есть - двойной клик не выделяет его весь - так что да, неудобно...
Но id 112366544 - безусловно человекочитаем и даже человеконабираем.
Конечно это важно при эксплуатации, но все эти идентификаторы всё равно только копи/паст - читать и набирать там нечего...
Он заметно более читаем. И копипастить проще, ага. И даже в запросы вставлять проще, они не раздуваются нейпоми как.
23880000338 - вот это заметно более читаемо? Точно такое нужно читать??? И это просто очередной инкриментый id
Учитывая что такой id всегда копи/паст. И я буду утверждать ВСЕГДА копи/паст, иначе можно один нолик при человеко-читаемости и человеко-писаемости пропустить/добавить и усё - денежки ушли не туды...
Ну а раз всегда копи/паст - то остаётся только: ну чутка поудобнее, ну чутка по привычнее, ну запросы покороче выглядят...
А прибытка в том, что UUID генерируется на стороне клиента (фронта/бэка, но не на стороне db) - очень много...
Да. Особенно когда их десяток в одном запросе и надо все верно скопипастить ничего не перепутав.
А как вы будете баги в стейте искать не читая и не дебажа запросы? Я вот так не умеют.
Вреда гораздо больше. Не надо так.
Я так понимаю вред от UUID в сложности дебага запросов...
Если у вас десяток нужен при дебаге и они вот такие:
23880000338,28880000338,23880000838,28880000888,23880000388 - копипастить такое Г - да, тяжко.
Понимаю, тяжко, а с UUID будет ещё тяжелее!
Но не понимаю как архитектор вдруг решиться прислушаться к вашей проблеме и поведётся на простоту написания запросов...
А как вы будете баги в стейте искать
тут я не понял
Разницы искать что-то типа 28880000338 или 019c61a1-dc83-7b47-ad06-3c37113cc535 конечно есть, но не такая чтобы проектируя архитектуру к этому прислушиваться
Архитектор это кто? Тот кто не эксплуатирует систему и витает в облаках теории? Почему на его мнение надо обращать внимание? Почему бы его не уволить завтра? Ну или перевести в обычные сеньоры, чтобы понял как люди работают на практике и какие задачи решают.
Системы надо не только делать, но и эксплуатировать потом. А это подразумевает копаться в кишках и айдишники нужны часто. И всем лучше если тот кто ловит багу будет ловить багу а не думать все ли он верно скопипастил или почему оно не воспроизводится?
Ну уж точно не тот, кому размер запросов и сложностей копи/паста может помешать правильно делать фичу.
Одним тяжко запросы к базе отлаживать, другим тяжко логи фильтровать, третьи привыкли к rest api и не согласны кафку внедрять, четвёртые на фронте либу подключить не хотят и т.д.
Всем что-то не нравится, у всех самые обоснованные причины делать не так, а иначе.
Ну и id в форме UUID - позволяет и в кишках копаться и эксплуатировать и насаживать новые баги и искать старые.
Ну а то что кому-то чего-то неудобно, ну тут уже сорян. Тут неудобно, а тут другим не просто удобно, а критически важно.
Критическая важность все еще непонятна. Для публичной ссылки с псевдозащитой гуид положите в отдельное поле. Не возражаю. А остальное не нужно.
Больше полей богам db
Ну уж нет. Никаких 2х полей, каждое из которых "типа" уникально идентифицирует... Обойдётесь, реально.
Вот вам UUID - мы создали заявку с ним, а теперь будьте добры отвечать по этому UUID: что с ней? уже создана, уже проверена, уже передана, уже обработана, уже возвращена, аааа - отказано...
А не так: мы хотим создать заявку -> ща, сек, я тут сгенерю ей id и дам... прошло 10 сек... погодите, мы ещё не уверены, что этот пользователь достоин создания заявки... 5 сек... вот 4593876 всё готово
Странные у вас системы. Это все работает за миллисекунду. Само.
Поля это хорошо. Вот вам удобный и понятный PK. Вот вам гуид и немного прикрытая от перебора ссылка. Удобно всем, все довольны.
Милисекунда между чем и чем?
Между командой SQL insert и ответом?
А между фронтом в узбекистане, бэком принимающим там этот запрос, продюсером, кафкой, консюмером, бэкендом в мастер_хабе, хождением за проверками и наконец командой insert, а потом всё по цепочке обратно... и на каждом шаге следуем понимать, что всё порвалось
Асинхронные пайплайны не так строятся. Клиент не должен ждать если у вас очередь на пути запроса.
А синхронные запросы работают за миллисекунду.
Отлично, и как мы с автоикриментом в базе построим асинхронную систему?
Разными способами. Таких систем построено море. Возьмите ту к которой у вас доступ есть и посмотрите.
Отлично, и как мы с автоикриментом в базе построим асинхронную систему?
Например, так, как в Microsoft построили Active Directory. Каждому КД (узлу, хранящему базу данных) выделяется (для созания SID) последовательный диапазон чисел, и он, пока не выйдет за диапазон, число для следующего SID с автоинкрементом. При подходе к концу диапазона - запрашивает у специально обученого КД (RID Master), который знает, какие диапазоны уже выданы , новый диапазон. И так оно живет уже более 15 лет в куче организаций в мире.
Там, конечно, задача попроще - объекты, у которых есть SID создаются не часто - но решение получается полностью асинхронным.
Вы такое готовы потащить к себе для rps 100 - пусть и не хайлоад, но уже нормально так...
Мне вот неохота...
Мне так и не объяснили, зачем, что-то такое тащить.
Конкретно что такого, что создатель сущности и создаёт её id в формате UUID
Она вполне может и не возникнуть, сущность эта, не добралась до базы и не возникла, отлично. Доберётся и возникнет в базе - вообще зашибись.
Но, зато по пути она уже идентифицирована единообразно и уникально.
У меня возникает иногда очучение, что у всех фронты (клиенты) просто напрямую с помощью SQL кода ходят в базу... и все тока и думают, как питонистов не пустить напрямую в базу.
Вы такое готовы потащить к себе для rps 100 - пусть и не хайлоад, но уже нормально так...
Мне вот неохота...
Не вижу причин, почему бы не использовать. Размер диапазона можно выбрать достаточно большим. Под rps следует иметь в виду вставки, да? Все остальные операции с генерацией первичного ключа не связаны, правильно? Так вот, если выбрать для 64-битного ключа рамер диапазона что-то в райщне милллиона (~2^20), то один диапазон займет крайне малую долю идентификаторов (1/2^44), запрашивать следующий диапазон вполне можно заранее, при исчерпании, допустим, половины текущего. Тогда при этом вашем rps=2^7 время на то, чтобы его получить (совершенно асинхронно), будет ~2^13 секунд, т.е. больше двух часов. Вам мало? Доверять же фронту создавать первичный ключ - это несколько рискованно, не находите? А тогда и разницы никакой нет, будет ли ключ автоинкрементным i64 (создается бэком или вообще СУБД) или же UUID (.создается примерно там же). Автоинкрементный ключ имеет для индексов примерно те же преимущества, что UUID v7 (vs UUID v4).
Ну, а фронт получает первичный ключ от API как ответ на операцию вставки (если у нас CRUD), и может дальше его использовать по своему усмотрению.
PS Проблемы питонистов меня не волнуют: я этим современным заменителем Basic'а не пользуюсь.
Доверять же фронту создавать первичный ключ - это несколько рискованно, не находите?
Вот. Ключевое!
Если первичный ключ UUID v7 то я действительно не вижу абсолютно ни каких рисков в его создании на фронте.
А прибыток вижу.
Если первичный ключ UUID v7 то я действительно не вижу абсолютно ни каких рисков в его создании на фронте.
"Не вижу" - это аргумент, да? Особенно когда его применяют не к конкретному приложению а вообще ко всем приложениям?
А какой аргумент тут может быть ещё?
Есть работающая в течении 4х лет система, состоящая из множества независимых команд, обеспечивающая через этот паттерн платежи, сбоев связанных с тем, что фронты генерят UUID нет. Все по цепочке их передают и используют. Кто-то у себя этот UUID возможно НЕ использует как РК, а кто-то использует как PK в своей базе.
Какой аргумент ещё нужен.
Ни кто, риски привести не может...
Запросы при int-ах не раздуваются... давайте сделаем вид, что этого ни кто не видел...
На совещании при проектировании очередной системы, такое не стоит произносить.
На совещании достаточно сказать "СИБ автоинкремент разрешает и это удобнее нашей разработке". Вопрос закрыт.
А другая часть на совещании скажет, а нашей разработке это неприемлемо.
Поскольку:
1. Завтра защиту от перебора, и переделку всех фронтов и бэков будет делать ваша "разработка"? За Ваш бюджет и в ваши выходные?
2. Когда придут с новыми бизнесс-проверками на этапе создания ID и проверки эти будут предусматривать 30 сек задержки (сходить по http в соседнюю команду, что-то посчитать...) - кто на будет всё переделывать - новые экраны с лоадерами делать, обрабатывать пользователей которые не хотят ждать 15 сек и закрывают экран после отправки запроса, потом открывают и делают запрос заново... Ваша команда? Нет, ну так и всё.
Изменение ТЗ - новая работа для разработки тестирования и всех вокруг. А вы как хотели? Делать монстра без ТЗ никогда нельзя.
По этому сейчас в ТЗ так и запишем - генерация PK id будет на стороне клиента в виде UUID
Через меня такое не пройдёт. И через СИБ не пройдет.
Писать то можно все. Согласовать не выйдет.
Ну так и строчка в ТЗ что сервер базы генерит автоинкриментный PK ID тоже не пройдёт.
Фичу закрываем на этапе согласования ТЗ )))
На практике автомнкремент и согласовывать не надо. Это дефолт который по умолчанию. Если сильных доводов против нет значит берём его. На моей памяти ни у кого из не было еще.
Вопрос не в типе поля для PK id
Вопрос в том, кто его создаёт! И что будет когда для создания записи и генерации id потребуется 20-25 сек, а потом 40-45 сек... Не по технической причине, а по причине "обязательных" бизнесс-проверок, что-то получить, что-то проверить... Время всей цепочки, от фронта до db и обратно...
Да, если сервер выписывающий id (не сервер бд, а сервер куда идёт фронт) поклянётся на крови, что на запрос от фронта, максимум через 1 сек отдаст id, всегда - то не проблема, пусть автоинкримент.
Но и переделка будет уже за счёт того кто клянётся.
Вы там БД на счетах запустили? Получение значения из сиквенса примерено моментально. Оно возвращается клиенту в ответе на запрос создания сущности.
Понимаю, вы полагаете, что всё начинается с команды insert ну и на её ответе всё заканчивается. Как она на db попала - сие проблема не базадиста... У вас ведь всё за милисекунду - всё замечательно.
фронт (узбекистан) - бэк узбекистан - синк_нод узбекистан - кафка - синк_хаб - мастер_бэк (проверки 5 секунд) - мастер база (микросекунда) - всё обратно...
И если фронт генерит UUID то все службы вашего любимого саппорта и ваших нежных писателей запросов - ходят с одним и тем-же UUID и спрашиваю - а какого фига мы вам послали, а вы не ответили... аа у вас обслуживание ночью было... понятно
В вашей выдуманной системе серьезная проблема с архитектурой. Так системы не делают.
Синхроннысистемы это буквально сходили в бд и вернули пользователю ID. Асинхронные это приняли пачку данных на обработку с ожидаемым временем в минуты а то и часы и отпустили пользователя. Обновляем статус обработки по возможности.
Статус обработки чего? id того чего статус нужно узнать кто создаёт?
Я же показал, хоть пачкой хоть бочкой, кто выписал id?
Ну и как я понимаю, при синхронных вы всегда сделаете автоикримент, но при асинхронных "как-то по другому"
Получили два разных паттерна
Может не стоит так и всегда делать удобно всем, а не базадистам...
Это не выдуманная система, это просто распределённая, текущая, работающая уже года как 3
Её расширение не зависит от числа промежуточных узлов и необходимости анонимизации или шифрования данных на трансграничных переходах, и всяком таком прочем.
А расчёт, что вот эта фича сейчас синхронная и останется синхронной - это закладывание себе самому переработок. Сегодня синхронная, а завтра - упс уже нет.
У пачки данных есть своя таблица. В ней есть свой ID. Вот его и вернули клиенту чтобы мониторить как там его пачка данных едет. Его получение синхронно и не занимает времени.
Синхронные фичи и асинхронные настолько разные что в любом случае переделывать все. Не надо оверинжинерингом заниматься.
Ага, на каждом этапе свой id - это мечта саппорта и отладки фичи.
А тут и нет оверинжиниринга, источник создают id и всё, проблем нет: ни с саппортом, ни с отладкой, ни с безопасностью, ни с перебором, ни с сортировкой v7
Вероятно есть проблема с привычкой
Разные сущности - разные ID. Это база. Пачка пришедшая на асинхронную обработку это точно отдельная сущность.
Согласен, пачка заявок на переключение тарифов, точно отдельная сущность. Ну а одна заявка одного пользователя в первой пачке и потом эта заявка уже в следующей пачке ну конечно конкретная заявка этого пользователя возвращаемая в почке результатов - это всё три разные сущности.
Ведь в базе сформирована "истинная" сущность 654445876
Остальные "мнимые".
Истина она в базе. Саппорт идёт лесом, клиент туда-же вместе с мобилкой...
К нам претензии есть - нет и быть не может, нам всё ИСБ согласовало, какие к нам могут быть претензии.
Видите и запрос легко писать и работает он быстро... а в какой пачке и где потерялась ваша конкретная заявка, в какой кафке, на какой проксе - это не к нам, а к кому, да мы не в курсе - там где-то...
Конечно отдельная. Любая куча чего-то это отдельная сущность. Люди любят отслеживать статус своих батчевых операций. И историю по ним смотреть любят. Значит табличка и сущность.
Истина естественно а безе. А где ей еще быть? Источник правды должен быть один, должен быть абсолютно надежен и должен быть под аудитом. Что это как не база?
Любая куча чего-то это отдельная сущность.
А сама (одна заявка) входящая в пачку - сущность?
И если да, то почему на этапе её жизни фронт-бэк-пачка-кафка-бэк у неё один идентификатор, а после её создания в базе - у неё уже появляется второй идентификатор...
И все дружно психуют, что думают про конкретную заявку с id 654454, а другие ищут и думают про заявку 91122111, ой а третьи вообще воспользовалиcь id 55655 - который id пачки...
В целом статья мне понравилась, но ее нужно "полировать".
-- Распределённая система / микросервисы:
id UUID PRIMARY KEY
DEFAULT gen_random_uuid() -- v4
-- Или генерируйте UUIDv7 на стороне приложения
После появления встроенной функции uuidv7() в PostgreSQL не осталось ни одного разумного аргумента в пользу UUIDv4. Заранее отвечаю тем, кто боится раскрыть дату и время генерации UUIDv7, - функция uuidv7() позволяет исказить эту дату путем смещения значения таймстемпа даже не на дни, а на тысячелетия, причем очень удобным и безопасным способом.
Совершенно непонятно, зачем в случае микросервисов нужно генерировать UUIDv7 на стороне приложения, если есть такая замечательная встроенная функция uuidv7() в PostgreSQL, формирующая таймстемп с точностью 250 наносекунд.
В случае распределенной системы удобно иметь два ключа в записи: один генерится на клиенте (для сверки), а второй на сервере (для лучшей монотонности ключей, первичный ключ) - функцией uuidv7(). Об этом упоминается в RFC 9562:
Applications using a monolithic database may find using database-generated UUIDs (as opposed to client-generated UUIDs) provides the best UUID monotonicity. In addition to UUIDs, additional identifiers MAY be used to ensure integrity and feedback.
После появления встроенной функции uuidv7() в PostgreSQL не осталось ни одного разумного аргумента в пользу UUIDv4.
Есть такой аргумент. Функция появилась в последней версии слоника, а миграция, во-первых, не всегда возможна в принципе, во-вторых, не всегда возможна в адекватные сроки. В-третьих, работает - не трогай.
Т.ч. не всё так однозначно.
Для старых версий PostgreSQL рекомендую расширение pg_uuidv7.
Миграция - слишком громкое слово. Достаточно только заменить прежнюю функцию генерации UUID на uuidv7(). Это возможно всегда, быстро и без побочных эффектов. Ни столбец с типом данных UUID, ни прежние UUID трогать не надо. В одном столбце с типом данных UUID мирно уживаются UUID разных версий. По мере роста количества свежих UUIDv7 скорость работы БД будет увеличиваться.
В-третьих, работает - не трогай.
Значит, еще не припекло. Когда БД начнет с трудом ворочаться, тронете.
Предпочитайте мягкое удаление для критичных бизнес-данных
Я просто оставлю это здесь.
Во! Вспомнил! Как же я этот момент упустил? Старею, старею...
Шпаргалка по именованию
Не используйте ключевые слова SQL/СУБД в наименованиях объектов. Посгрес с помощью ухищрений, например, разных, позволяет такое делать, но сопровождать подобные "продукты" - это БОЛЬ И СТРАДАНИЯ.
Правильно! и не использовать нестандартные символы в наименованиях.
Интересно, что нестандартный символ в стандартных расширениях использовалался для расширения uuid-ossp, что позволило затруднить его установку и уменьшить распространение uuidv4:
postgres=# create extension uuid-ossp;
ERROR: syntax error at or near "-"
LINE 1: create extension uuid-ossp;
^
1. Всегда используйте суррогатный первичный ключ
Критичность: максимальная
Сорри, но дальше можно не читать. Начал за здравие - проектирование, а потом...
Суррогатные ключи имеют полное право на существование, но всегда - это бред.
Вангую, автор носки дома тоже все пронумеровал и именно UUID'ом, чтобы купленная вчера пара имела, условно, номера 1 и 1000000. Зато теперь найти легко. Автор не сталкивался с сопровождением реально больших систем, например АБС, с реальными данными, IMHO, где наличие суррогатных ключей одна из основных проблем производительности.
И да, наконец-то в PG завезли uuidv7, в какой версии - 18? В коммерческих БД, например, db2, генерация unique с незапамятных времен прошлого века была построена на ts, чтобы можно было использовать для нормального индексирования и, как следствие, шардирования.
Ничего не мешало генерировать uuidv7 на уровне приложения, так что так себе упрёк.
автор не нумеровал ничего, он просто попросил ии сделать ему статью. И зачем я все еще читаю хабр…
Вы не нумеровали свой комментарий, но я же не обвиняю вас в том что его написал ИИ. Хотя…
Я не обвиняю, это не незаконно. Я просто устал от подобного контента. А вот вам комментарий от ИИ:Статья выглядит как добротный чек-лист для начинающих, но подаёт многие решения как универсальные, игнорируя реальные trade-offs высоконагруженных систем. Почти не затронуты вопросы write-path, миграций без даунтайма, партиционирования, работы с MVCC и масштабирования, а без этого рекомендации остаются академическими. В продакшене такие «железные правила» часто приходится осознанно нарушать ради производительности и эксплуатационной устойчивости.
Носки не пронумеровал, но идея хорошая, спасибо. А если серьёзно вы правы, что в крупных системах суррогатные ключи могут быть проблемой. Но статья не для архитекторов банковских систем она для тех, кто завтра сядет проектировать свою первую базу. И для них "поставь суррогатный ключ» безопаснее, чем "подумай" потому что они ещё не умеют думать в этом контексте.
например АБС, с реальными данными, IMHO, где наличие суррогатных ключей одна из основных проблем производительности.
А вы размер поля (BIGINT vs UUID) с, собственно, типом ключа (натуральный/суррогатный) не путаете? Что-то мне подсказывает, что есть такая буква (путаница понятий) в этом слове.
Ибо причина использования суррогатного ключа, а именно - естественный ключ может быть изменён, что приведёт к каскадному обновлению соответствующих записей в дочерних таблицах - вполне себе веская и имеет место быть.
Разрешите поинтересоваться в целях повышения образования. (ц)
А можно пример несуррогатного ключа, который на дистанции хотя бы в 10-20 лет 146% не изменится?
СНИЛС говорят не меняется, VIN
СНИЛС говорят не меняется
Не меняется, но их может стать несколько. Да, это неправильно, и остаться должен только один, но важен сам факт: теоретически номер СНИЛСа может измениться.
Сорри, но дальше комментарий можно не читать.
Вот когда вы точно уверены что это это внешне значение можно использовать как первичный ключ? Сегодня мы думаем что у нас у пользователя email - уникальный, а завтра он поменяется, или вообще будет две копии пользователя с одним email но второй будет помечен как deleted.
И когда ключи стандартизированны - типа всегда число. То можно в коде писать generic квери для обработки кучи разных таблиц одинаково.
На счёт перфоманса не понял - если там нет индексов, то в чём проблема?
не путаете суррогатные и композитные?
Вот начитается молодёжь таких советов от нейросетей, а потом коноплю свою колють.
Всегда используйте суррогатный первичный ключ
Не всегда. Для ссылочных сущностей - оправдано.
Таблица курсов валют. Дата, Валюта, Курс.
Объясните здесь смысл поля id?
Каждая таблица ОБЯЗАНА иметь created_at и updated_at
Не обязана. Должна быть целесообразность. Не надо категорических суждений.
Та же таблица курсов валют. Ее можно хоть всю передавать, хоть загрузить из интернетов.
Показания промышленных датчиков или (вписать любое, что льется в базу миллионами строк в час и не предполагается к синхронизации в разных базах)
Чеки в магазине. Где есть шапка чека и товарное содержимое чека (намертво привязанное к шапке). Поля в шапке оправданы, а в строках они зачем?
Используйте TEXT вместо VARCHAR(n)
Тут вопрос скорее понимания структуры БД.
Открыл поля таблицы и примерно понятны ограничения, если указан VARCHAR.
Если TEXT, то возникает ощущение, что можно туда запихать гигабайтный XML.
Используйте BIGINT / BIGSERIAL для ID, а не INT
Я бы посоветовал: используйте uuid7 для id, если база не требует экстремальной производительности.
Позволяет избежать огромного числа проблем при синхронизации между разными базами или замены id (а такое тоже случается).
ВСЕГДА определяйте явные внешние ключи
Тезис спорный. Зависит от профиля нагрузки и от логики приложения.
Достаточно актуальная проблема для мобильных устройств, когда из леса вынырнул пользователь с приложением 3-х годичной давности. И вам надо его протащить через 50 версий обновления.
С внешними ключами это еще та морока, не забыть словить какой нибудь каскадный update или delete. Нет, оно решаемо, но без ключей сильно проще.
Используйте CHECK-ограничения для валидации данных
Тезис достаточно спорный. Зависит от приложения. Иногда, лучше оставить логику проверки самому приложению.
"Ограничения в БД — это последний рубеж обороны, и они работают всегда."
И тут программисты приложения, которые ничего не знали про эти ограничения в БД (т.к. БД занимается отдельный человек) хватанули полную панамку этих ограничений, выкатив новую версию.
На их базе все же работало!
Создавайте индексы для каждого WHERE, JOIN и ORDER BY
Да щас!
Нейросеть, которая это писала явно не работала с большими ERP-системами, где количество комбинаций полей в WHERE, JOIN и ORDER BY - огромное.
Следуйте этому совету и у вас 90% базы будут занимать индексы. А время записи в любую таблицу будет на 90% состоять из обновления страниц индекса.
Используйте EXPLAIN ANALYZE перед деплоем запросов
Программисты каждый запрос будут прогонять через EXPLAIN ANALYZE и тратить время на анализ.
И у каждого программиста есть доступ к рабочей базе, где он может проверить как запрос действительно отработает (а не база в 5 мегабайт для разработки).
А еще единороги едят радугу.
Два слова: Нагрузочное тестирование.
Используйте пулинг соединений (PgBouncer)
Зависит от профиля нагрузки. Для web приложений, где время жизни транзакции\запроса (в итоге соединения ПО-БД) небольшое - ОК.
Если это кровавый энтерпрайз, где транзакция может состоять из сотен запросов и занимать несколько секунд, то с увеличением числа пользователей, начнет расти кол-во соединений на PgBouncer.
А как вы знаете (надеюсь) он работает в одно ядро. И в районе 150-200 соединений, ваше приложение начнет получать ошибки соединения с БД т.к. ядро будет загружено на 100%.
Даже самые оптимистичные его бенчмарки дают 200-300 соединения с БД. Но я проверял - 150-200 и все, кранты.
Да, можно поднять несколько процессов PgBouncer, но там поднимается процесс координатор и (скорее всего) откажет именно он (не стал проверять).
Всегда используйте транзакции для многошаговых операций
Этому учат на второй странице любой книги по БД.
Если разработчик это не понимает, то лучше вообще к БД не подходить.
Таблица курсов валют. Дата, Валюта, Курс.Объясните здесь смысл поля id?
Валюта российский рубль имела обозначение RUR, а с 1998 года стала RUB. И это не единственный такой пример. Не существует в природе гарантированно неизменных и уникальных натуральных ключей. Например, известны дубликаты ИНН, MAC-адресов. А ключ для связи таблиц (поле id) изменяться не должен.
Каждая таблица ОБЯЗАНА иметь created_at и updated_at
Не обязана. Должна быть целесообразность. Не надо категорических суждений.
Та же таблица курсов валют. Ее можно хоть всю передавать, хоть загрузить из интернетов.
В этом случае будет только актуальная таблица. А если в целях аудита понадобится посмотреть или вставить в расчеты ошибочные исторические данные?
Я бы посоветовал: используйте uuid7 для id, если база не требует экстремальной производительности.
Я уже устал опровергать взятый с потолка миф, что UUIDv7 якобы снижает производительность по сравнению с целочисленными ID.
С внешними ключами это еще та морока, не забыть словить какой нибудь каскадный update или delete.
Никаких update или delete с ключами происходить не должно. Ключи должны быть вечными и неизменными. Значения атрибутов и связей могут изменяться с течением времени - для этого есть поля valid_from и valid_to (или их синонимы start_date и end_date).
Внешних ключей (и других ограничений) не должно быть только у таблиц, куда загружаются сырые данные, чтобы загрузка происходила без помех. Потом эти данные всё равно нужно валидировать, прежде чем использовать.
С rur rub пример не валиден - это же валюта другая стала.
Вообще я бы общее правило сделал - если ваше приложение данными не владеет, а просто сохраняет как есть, то тут суррогатнай ключ не нужен. (С другой стороны не всегда ясно какой тут натуральный ключ использовать, но в моей практике обычно понятно было) И курсы валют как раз хороший пример - всё что вам дали и вы записали как есть.
Но если ваше приложение создаёт данные - то оно и ключ может записать.
Это неудачное правило. Тот, кто присылает данные, может изменить свой классификатор, и что тогда делать?
Ну это от вашего кейса зависит - если вам просто данные сохранить, не смотря в их структуру. То конечно не нужно к ним привязываться - просто как byte array сохраняете и всё. Но если нужно как то следить чтобы они не повторялись при обновлении, то надо смотреть как они там устроены. И если их структура поменяется, то да, у вас тоже нужно поменять схему и т.п.
Самое главное правило при проектировании высоконагруженных приложений/бд для postgresql - минимизировать количество частых update и delete. Иначе вечный геморрой с вакуумом.
Натуральные ключи (email, ИНН, username) меняются. Когда это произойдёт, вам предстоит каскадное обновление миллионов строк и всех FK-ссылок. Суррогатные ключи (BIGSERIAL / UUID) не меняются никогда.
Я сейчас пробую использовать свой генератор ключа для юзера. Комбинирую уникальный номер пользователя с ФИО, записываем его в одну строчку без пробелов и спецсимволов, через тире: например "9999999-ИвановАА". Вставляем этот сгенерированный string в поле как ключевое id.
Этот айдишник планирую вставлять везде при операциях с данными в таблицах, будет выделен специальный столбец createdBy. И сразу видна фамилия того, кто вносил изменения в БД. На мой взгляд, удобнее будет читать аудитору.
На счет производительности, не уверен, пока не тестировал интересно что вы думаете?
Автор точно про высоконагруженные приложения пишет?
Внешние ключи и индексы на каждый чих убьют любую БД и Postgre здесь не исключение.
Высокая нагрузка почти всегда требует денормализации, а про это ни одного пункта не увидел. После FK и индексов на каждый чих дальше просто пролистал.
Автору рекомендую скрыть статью, пока минусов не нахватал.
Автор решил поделиться своим опытом в проектировании базы данных. Изложил свои правила и вынес не обсуждение. Самое главное, что для себя Автор при проектировании базы данных опирается на свои правила (это позволит понять другим участникам проекта, почему принято то или иное решение), а то что эти правила не претендуют на обобщение - это уже другой вопрос. Если каждый разработчик имеет свой набор правил - это хорошо, проще разобраться в проекта. Хуже, если нет вообще каких-то правил, или эти правила вообще не документированы и когда тебе эта база данных сваливается в сопровождение, то начинаются хождения по мукам. Статью стоит рассматривать, как обмен опытом проектирования, с чем-то соглашаться с чем-то нет, корректировать свои правила. В целом статья полезная, раз столько комментариев.
Мне вообще статья понравилась.
Есть llm, есть спорные моменты, но у нас же не научное сообщество, а инженерное и тут как известно нет серебряной пули - для какого-то приложения всё это будет работать, а для другого - нет. Так что хорошо что обсуждаем. И автор в комментах дискуссию ведёт, а не просто запостил. :-)
Мне вообще статья понравилась.
Есть llm, есть спорные моменты, но у нас же не научное сообщество, а инженерное и тут как известно нет серебряной пули - для какого-то приложения всё это будет работать, а для другого - нет.
Если я правильно понимаю русский язык, то слово "железный" в заголовке означает, что эти правила должны работать всегда.
Нет такого правила, которое будет работать на 100%. А заголовок просто маркетинговый ход. Эти правила работают в большинстве случаев. Но если у вас проект на 10 человек, вы не обязаны соблюдать все правила ведь это стандарты крупных компаний, где любая ошибка означает потерю денег и, возможно, доверия клиентов. Чем надёжнее структура базы данных в начале, тем проще вам будет в дальнейшем.
Ха ха, да, есть такое. :-)
Но вот железо обычно тонет, но не в ртути. Вот может эти железные правила обычно работают, но в некоторых условиях - нет :-D
Спасибо мне приятно слышать что моя статья вам понравилась. И мне нравится делать дискуссию ведь я тоже чему то научусь или научит кого то. Так что все в плюсе
5. Используйте BIGINT / BIGSERIAL для ID, а не INT
Serial типы — это прошлый век. Уже давно следует использовать identity
15. Используйте ENUM осторожно — предпочитайте CHECK или справочные таблицы
-- ✅ Правильно: CHECK constraintstatus TEXT NOT NULL CHECK(status IN ('draft','published'))
Но ведь это не так экономично, как ENUM, что критично когда строк много. ENUM значение занимает 4 байта, даже если там длинный текст.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
25 железных правил проектирования баз данных в PostgreSQL