Рекомендации по выбору типа данных в SQL-таблицах

Как раз сегодня на эту тему прочитал пост в блоге: https://thebuild.com/blog/2023/01/15/how-slow-is-decimal-anyway/

Decimal медленнее (в Postgres), но не запредельно медленнее.

Как раз сегодня на эту тему прочитал пост в блоге …

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

OLAP и DWH смотрят на это как на..

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

А если тебе софт писать - то строго нахер и логика только в коде. Точка.

До сих пор живы проекты, написанные на SQL. То есть вся, блин, бизнес-логика в БД на функциях, триггерах и пр. Приложуха только стучится в дверку и получает ответ, все осмысленное в БД происхоит. Вот такой подход сейчас как бы не очень… :) :) :)

Приложуха только стучится в дверку и получает ответ, все осмысленное в БД происхоит. Вот такой подход сейчас как бы не очень…

Почему «не очень»?

Мне кажется, что наоборот - самый правильный подход.

Допустим есть погреб с картошкой. Допустим есть задача отсортировать картофелины по размеру. Как лучше - вытаскивать по ведру из погреба, сортировать и обратно затаскивать или спуститься в погреб и там всё отсортировать?

SELECT * FROM auth_user ORDER BY date_added DESC LIMIT 10;

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

А как надо?

Мальчик, иди учи

Классика столкновения программиста с людьми из реального мира. Растерянность, страх, агрессия, императивы, искажение фактов.

Я, кстати, без гугла помню определение риска из ИСО (очень изящное, кмк). А ты? Мне отвечать не надо, ответь себе.

По факту возражения будут, или только пуки в лужу?

Аналогия так себе.

А если тебе софт писать - то строго нахер и логика только в коде. Точка.

Тогда и реляционная БД непонятно зачем нужна. Бери любую K-V, да пиши всю логику в коде. Но так почему-то мало кто делает.

По факту чего? того, что пять деноминаций за XX век — это «раз в 100 лет»? Нет, конечно, ты тут абсолютно прав.

Аналогия так себе.

Ну, извините.

Есть ещё хуже - я когда начинаю сильно нервничать, то людям рассказываю аналогию про «купить мерседес только для того, чтобы хранить в багажнике картошку».

Тут просто не сильно нервничал.

Почему «не очень»? Мне кажется, что наоборот - самый правильный подход.

Да бог с тобой :) :) :) Подход ужасный!

Потому что:

1. Масштабируемость страдает.
2. Поддерживать такой софт - боль. Представь, что половина обработки у тебя в БД, а половина в коде и надо что-то в логике изменить.
3. observability страдает.

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

Я только про то, что бизнес логики в БД быть не должно, она должна быть только в коде.

Тогда и реляционная БД непонятно зачем нужна. Бери любую K-V, да пиши всю логику в коде.

Звучит так, как будто реляционную БД используют только, если ее средствами надо выполнять какие-то вычисления, лол :)

Реляционная БД нужна потому, что она:

1. быстрая;
2. предоставляет определенные гарантии (читать про приципы ACID).

Если у тебя нормализованные данные то ничего быстрее и надежнее не придумаешь.

половина обработки у тебя в БД, а половина в коде

Вот так - точно не надо делать.

Всё в процедурах/функциях.

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

А пишешь в процедурах - любая хотелка начальства реализуется мгновенно и максимально близко к обрабатываем данным.

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

Спрошу проще, какие проблемы ты видишь в таком подходе?

В смысле? Я ж вроде написал, какие проблемы вижу.

Ну и резко возросшие шансы потерять работу при переходе конторы на режим «БД=только хранилище» - тоже проблема, можно сказать.

Реляционная БД нужна потому, что она:

1. быстрая;

Так k-v базы обычно намного быстрее

2. предоставляет определенные гарантии (читать про приципы ACID).

Многие k-v базы предоставляют такие же или похожие гарантии.

С логикой в БД вроде две основные проблемы это:

1. То, что она не версионируется или плохо версионируется. Для обычных языков программирования придуманы VCS, неисчислимые способы тестирования, редактирования, деплоя. Для БД этого либо вообще нет, либо в зачаточной стадии, жутко неудобное.

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

Кхм, это ж разве проблмы :)

Пункт 1 решается миграциями.

Пункт 2 вот я об этом и говорю, что логика в коде - это прозрачно, а логика в БД - это удел мамонтов и bus-factor в компании :)

Но это еще не все же. А что будет когда вы упретесь в производительность базки? Железа докинете? :) :) :)

А если данных станет жирновато, тогда что? :)

Так k-v базы обычно намного быстрее

Истинно так. Интересно, почему же, в сравннии с реляционными?

Многие k-v базы предоставляют такие же или похожие гарантии.

НЕТ, и именно поэтому они быстрее :)

Everything comes at a cost.

В смысле? Я ж вроде написал, какие проблемы вижу.

Я как раз про проблемы подхода «логика в БД» спросил. В таком подходе проблем нет?

Ну и пара каментов:

Пишешь на компилируемом языке - получаешь пересброку кода на каждое шевеление.

Во-первых, это происходит не каждые 5 минут. Во-вторых, от языка зависит. К примеру, приложуха на Go соберется «с нуля» за минуту-полторы, а если менять, скажем только один пару файлов в проект - за секунды (кеширование умное сильно). Поэтому хоть после каждой строчки кода персобирай. Ну и такой себе в целом аргумент, конечно…

Ну и я вот выше задал вопросы: что будет, когда упретесь в проивзодительность базки и что будет, когда таблицы разрастутся?

Ну если про картошку продолжить, то готовить её все же лучше не в погребе - так что кесарю-кесарево.

Что вы имеете в виду под «таблицы разрастутся»? 2ТБ на одну таблицу (секциями по 70ГБ) - это уже разрослись, или еще нет?

Кластеры, реплики, в конце концов новое железо, если ничего не помогло - и всё чудесно с «производительностью базки».

Единственный понятный аргумент в минус - про версионирование кода от emorozov, который вы почему-то перевели в какие-то «миграции», которые тут вообще никаким боком.

Я не хочу с вами (и не с вами тоже) спорить. Делайте, как хотите.

В случае добавления 100500 юзеров в наносекунду выборка последних 10 бессмысленна, если бизнес не устраивает примерно последняя десятка +- охулиард. Этого запроса к базе в реалтайме просто не будет.

Такая метрика скорее будет вычисляться до попадания данных в базу.

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

Ок, спорить не будем.

«Миграции» - это про поддержание схемы в понятном состоянии (врсионирование ее). Или вы просто создаете новые функции без возможности автоматического отката изменений?

Вот хотя бы такого плана базовые утилиты не используете? https://github.com/pressly/goose

Вот тут прямо интересно стало, если често.

Единственный понятный аргумент в минус - про версионирование кода

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

А код хранимок вполне себе версионируется и даже накатывается автоматически, но тут надо оч хорошо понимать, что и зачем делаешь =)

Вот хотя бы такого плана базовые утилиты не используете?

Нет не используем.

Вполне возможно, что просто не умеем.

Попробую посмотреть. И оно может помочь, когда несколько десятков разработчиков пишут код наполовину в ПГ, наполовину в MSSQL и процедуры должны быть согласованы ибо общаются между собой?

Было бы чудесно. Правда спасибо за информацию. Пойду, почитаю.

ЛОРовцы, не поддавайтесь на вопрос ТС-а, он просто пересдачу сдавал по БД (или экзамен, благо конец января это экзамены, а начало февраля это хвостатые идут во многих ВУЗ-ах), а тут аж 4 страницы нафлудили.

Пойду, почитаю.

Смотри, как это работает. Создаем файл, который накатывает разом все необходимое. Скажем,

0001-add-columns.sql

В нем пишем изменения:

-- +goose Up
-- +goose StatementBegin
alter table1 add column col(id serial, data text);
add or replace function x .... ;
-- +goose StatementEnd

-- +goose Down
-- +goose StatementBegin
drop function x;
alter table1 drop column col;
-- +goose StatementEnd

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

Запускаем миграцию вниз - применяются вторые два стейтмента и в служебной таблице делается пометка, что откачено.

Можно совсем атомарно применять: например, меняете одну функцию, но лучше, конечно, согласованно, чтобы из одного рабочего стостояния схемы получать другое рабочее состояние (т.е. чтобы не было такого, что один шаг откатили и оставили систему в неработоспособном состоянии. Это, впрочем, ИМХО.

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

Таким образом вы можете атомарно накатывать и откатывать изменения, ведь они, в конечном итоге, все делается sql запросами не более того. И иметь понятную историю. Как согласовать изменения в разных БД? Тут уже, наверное, надо подумать, если такой вопрос стоит.

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

Есть еще куча подобного. Я гошник, поэтому знаю, в основном, написанное на Go. Есть еще вот такой вариант (используем в проде в моей компании). https://github.com/golang-migrate/migrate

Но из этих двух goose мне нравится больше (в одном файле миграция вверх и вниз потому что) и goose многие крупные комании используют в проде.

Наверняка, можно найти еще с десяток решений со своими плюсами и минусами.

Рад, что информация пригодилась :) Я думал, это общее место и все знают :)