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

Схера ли?

В таких случаях перевод пользователя в прод базу можно рассматривать как ручную или полу-ручную операцию

Такую, что даже надо руками ID вбивать, а не использовать sequence?

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

ты хочешь посмотреть список 10 последних пользователей

А если твои date_added изменены вручную

Отмудохать того, кто так делает, табуреткой и объяснить, что для этого есть поле updated_at. Накатить бэкап, накатить, расслабиться.

Не знаю. Например из-за невозможности однозначно привести к lowercase букву I, ли ещё какой-нибудь гадости.

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

Ну и финтех, который не вкладывает бабло в разработку, обычно долго не живёт. Это я тебе говорю как человек, который работает в финтехе с аудитами и прочим.

https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names вспомнилось.

Буду_проституткой.jpeg

А с адресами все еще хуже.

Мораль: санкции, изоляция и всё такое – хорошо. И с именами можно работать только с русскими (ФИО и баста), и для адресов есть ФИАС с фиксированной структурой.

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

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

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

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

Можно верить, можно нет, но не надо меня переубеждать. Потому что опыт показывает, что любые assumptions, не подкрепленные железными constraint’ами, рано или поздно будут нарушены. Иногда с катастрофическими последствиями.

Тащемта эту проблему решают новые типы UUID.

Второй день рою интернеты про UUIDv7 и ULID. Такое впечатление, что они пока как-то очень теоретически решают.

Их сейчас уже использует кто-нибудь на настоящих прикладных рабочих базах?

ЛОЛ, какие ж вы питонисты тупые. Дырки не имеют значения по той же причине почему они не имеют значения для дат.

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

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

Хоть заобзывай меня здесь. Любой профессионал, проработавший достаточно долго, понимает: идеальных людей нет. Идеального софта нет. Идеального процесса нет. Идеальных организаций нет.

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

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

для адресов есть ФИАС с фиксированной структурой.

Ну-ну. Впрочем это сильно зависит от того, что понимать под адресом.

тебе не нравится то, что я обоснованно не люблю твой любимый язык PHP

PHP не мой любимый язык и мне в общем-то плевать на тебя и что тебе нравится или нет.

ты решил устроить какую-то личную вендетту

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

Криворукие разработчики, криворукие админы, ошибки в софте, да вагон причин, по которым это может произойти и всегда происходит.

Это всё замечательно, но это никак не относится к обсуждаемому вопросу о непротиворечивой выборке данных.

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

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

Мы недавно у себя перешли на UUIDv7 для ключей идемпотентности.

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

Значит, твои слова про то, что тех, кто сортирует не по pk, а по дате, надо сразу увольнять - абсолютная объективная профессиональная истина? Это у вас в PHP-шарагах так принято?

Что ж, мне вас жаль…

Ну-ну.

Поконкретнее пожалуйста.

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

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

Ну и финтех, который не вкладывает бабло в разработку, обычно долго не живёт.

Многие забывают, что разработка не заканчивается на прототипировании продукта, и забивают на автоматизацию оперирования. Sad but true.

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

Поэтому как и со всеми данными это, имхо, должна быть строка (сырые данные) и поля в соотв. с принятой номенклатурой – то, что удалось распознать.

Даже в России, где очень хорошая адресная система, есть куча нюансов…

Некоторые объекты могут одновременно принадлежать нескольким объектам более высокого уровня, например, парки могут быть одновременно в нескольких районах города.

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

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

В рамках одного субъекта могут быть одинаковые названия улиц. Даже в городах это есть, а уж в дачных поселках улиц лесная…

А еще есть плавучие рестораны/дома, которые стоят на вечном приколе и практически (а бывают и в реальности) вбетонированы в дно.

А ларьки на улицах?

И с именами можно работать только с русскими (ФИО и баста)

А иностранцы в России? А куча народностей со своими языками и традициями имен?

абсолютная объективная профессиональная истина

Я понимаю, что объективность для тебя это сложная идея, но да, это объективная истина.

Что ж, мне вас жаль

Смотри не заплачь, лалка.

ФИАС так-то это всё прекрасно переваривает, там есть такие странные адреса. Что в общем-то не удивительно, т.к. нужно просто вместо «улица» иметь другие приставки на все случаи жизни от «конура» до «космодром». Сложнее с хитровыдуманной нумерацией: где-то буквы, где-то дробь, где-то корпуса. Бывает ещё и всё вместе. Причём все это может означать совершенно разное отношение к реальным строениям. Т.е. где-то корпус будет отдельным зданием, а где-то просто пристрой.

А иностранцы в России?

Выслать и въезд запретить.

А куча народностей со своими языками и традициями имен?

Нии@%т. На госуслугах ФИО, чем я хуже.

varchar. Длина 20/200/2000. В зависимости от того, какая длина тебе кажется разумной. Для улицы я бы взял 200. Для компонентов имени по 200. URL 2000. Файловый путь 2000. Телефонный номер 200. Если 2000 не хватает значит это надо хранить в S3.

А вообще хранение улицы или отдельно имени это признак плохого дизайна. Если ты не Яндекс карты делаешь, тебе надо хранить весь адрес целиком или ФИО целиком. Компоненты чаще всего не нужны.

Я сделал свой алгоритм для генерации возрастающих ууид. Теперь везде его использую. Очень удобно. Рекомендую. Лучшее из двух миров, так сказать.

Хранить деньги стоит только интом в минимальных единицах. А то можно пожалуть потом :) Чтобы выдать некое визуальное представление в рублях - можно функцию запилить просто.

только интом в минимальных единицах

бигинтом

Только это не совсем uuid’ы, вероятно :)

https://datatracker.ietf.org/doc/html/rfc4122.html

Хорошо, если есть столько деняк :) Я про то, в первую очередь, что это именно целое число должно быть.

Хранить деньги стоит только интом в минимальных единицах. А то можно пожалуть потом

Ещё один любитель нести пафосную херню? decimal это и есть целый формат с фиксированной точкой.

Что у decimal с производительностью по сравнению с «простыми» целыми типами?

по сравнению с «простыми» целыми типами?

Зависит от реализации. Принципиально разницы нет.

Стандарты на ууиды я не понимаю. То, что я генерю, это в4. На всякий случай. Но кому на это не плевать я не знаю. По мне ууид это 128 битов чего то. И стандартная кодировка этих битов в строку и назад. Остальное это уже алгоритмы генерации, которые могут быть как стандартными, так и не стандартными. Зачем тратить драгоценные биты на запись алгоритма, которым это было сгенерировано, я не знаю. У меня это типа случайные ууиды. Ну а то, что они возрастают — ну вот так вот получилось.

случайные ууиды. Ну а то, что они возрастают

/0

Стандарты на ууиды я не понимаю

Вообще uuid были придуманы для того, чтобы гарантированно генерировать уникальные id в распределённой системе. Даже если узлы не имеют между собой связи. Такие uuid вообще не рандомные и даже упорядоченные в пределах узла. Так вот есть разные методы получения таких uuid. Соответственно нужно знать версию uuid чтобы его правильно интерпретировать (например узнать номер узла где он был сгенерирован).

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

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

Хорошо, если есть столько деняк :)

зато не придется переделывать схему при гиперинфляции

два разных узла не сгенерируют в одну микросекунду два одинаковых 62-битных числа

В одну нет, а не в одну очень даже вероятно. Требуется чтобы id не повторялись вообще, иначе нет никакого смысла в таких id.

И с именами можно работать только с русскими (ФИО и баста), и для адресов есть ФИАС с фиксированной структурой.

Сейчас казахстанские адреса и ФИО становятс актуальными.

Ещё один любитель нести пафосную херню? decimal это и есть целый формат с фиксированной точкой.

Сразу видно- деноминация обошла тебя стороной.

Что у decimal с производительностью по сравнению с «простыми» целыми типами?

decimal это ANSI -тип, реализуемый, обычно, как двоично-десятичный формат, т.е. по 4 бита на каждый десятичный знак. Могут быть очень длинными.

«Простые» целые типы, если поддерживаются, то это «нативные» типы целых. Разрядность таких чисел ограничена архитектурой процессора и денежки могут не влезть.

Это понятно всё. У меня отложилось, что в mysql DECIMAL самый «медленный» тип данных и если над полями этого типа идут расчёты в БД, то есть заметные просадки.

Но с другой стороны, IEEE 754 ведь расширили и для BCD давно, т.е. есть поддержка типа процессорами? Поэтому и вопрос, как оно на самом деле, очень давно с mysql имел дело.

деноминация

Событие которое происходит раз в 100 лет.

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

Там же 2 части. Одна от времени зависит, вторая случайная. Совпадение практически невозможно.

каждую наносекунду добавляется 100500 пользователей

автоинкремент работает через лок

Нет ли здесь противоречия?

Я думаю, идея в том, что зависит от юрисдикции и задачи.

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

Событие которое происходит раз в 100 лет

«Да мы по-любому с таким не встретимся».

Классика столкновения программиста с реальным миром. Прямиком из «Заблуждений программиста о …»

Ещё один любитель нести пафосную херню? decimal это и есть целый формат с фиксированной точкой.

Заюш, два вопроса к тебе:

1. чо такой грубый?
2. А я где-то сказал, что numeric/decimal это floats?

Ок, можно и decimal, конечно, но если подумать то можно прочесть в руководстве, что: «However, calculations on numeric values are very slow compared to the integer types, or to the floating-point types described in the next section.»

Для полноты картины можем еще подумать к какому типу в твоем языке программирования ты будешь приводить numeric/decimal. Не кажется теперь, что bigint попроще? Вот я, скажем, на Go пишу и получу из numeric массив байтиков, а из bigint int64 сразу. Ну и вот всрались мне эти конвертации?

Вот такие соображения есть от любителя нести пафосную херню.

И еще немного. Про замедление вычислений на уровне БД. Оно и понятно почему - потому что храним физически два инта и операции, с ними, естественно, усложняются.

Ой, кстати! Выходит, такая базка и места больше отожрет? Ну не сильно, конечно, хрен с ним…

И, внимание вопрос: для ЧЕГО мне утяжеление БД на ровном месте, потенциальное замедление вычислений на уровне самой БД (хотя это в принципе херовая практика что-то вычислять запросом; БД - это хранилище), а также замедление и усложнение кода (не забываем, что конвертация массива байтиков в int64 будет мне стоить миимум O(n), где n - длина массива)?

Это все ради чего, можешь мне пояснить? Вот и я не могу :)

Поэтому, может лучше bigint все же? :)

хотя это в принципе херовая практика что-то вычислять запросом; БД - это хранилище

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

Классика столкновения программиста с реальным миром.

Мальчик, иди учи что такое риск-менеджмент. Событие происходит раз в 100 лет и решается за 5 минут. Оно просто не стоит упоминания.