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

Есть к примеру модели пользователь, продукт и компания, нафига их сортировать по id?

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

SELECT * FROM auth_user ORDER BY date_added DESC LIMIT 10;

А где гарантия, что записи будут идти всегда строго по возрастанию pk? Даже с автоинкрементом это никто не гарантирует и полагаться на это - стрелять себе в ногу.

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

С ответом выше полностью согласен, может быть есть пример посложнее?

Секции (partition) или шарды?

INHERITS t TABLESPACE d + CHECK(id BETWEEN)

Рекомендую тогда уж копнуть глубже и выяснить, что на самом деле происходит в PostgreSQL при объявлении SERIAL или IDENTITY. Тем более, что копать несложно и неглубоко.

Как это в PostgreSQL работает я и без копания знаю.

И какое это вообще имеет отношение к обсуждаемому наезду, что «UUID ключи не нужны».

Никакое, потому что это был комментарий про инкрементные столбцы как артефакт MySQL - в том или ином виде они много где есть.

ORDER BY date_added

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

Даже с автоинкрементом это никто не гарантирует

Гарантирует, потому что автоинкремент работает через лок.

Не позорься уже, иди клепай формочки на джанге.

С ответом выше полностью согласен

Ну иди тоже уроки учи.

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

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

Ну-ну, и крутится на галактическом кластере. Как обычно :-P

Правда ответ сервера про 10 последних будет, увы, невалидным.

Гарантирует, потому что автоинкремент работает через лок.

Какие же вы PHPшники, пафосные неучи…

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

Не хочууууу, можно мне погулять?

минимально микросекунды

Да хоть что. Я думаю ты бы не хотел чтобы ПО твоего банка корректно работало только при определённых обстоятельствах.

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

Где гарантия, что в нумерации не образовались дырки и в дырки

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

попали новые пользователи хотя бы вручную

А если твои date_added изменены вручную? Что если на Марсе полнолуние? Будь хоть раз профессионалом: признай что был не прав и скажи спасибо что научили. А то так и помрёшь формошлёпом.

Сам-то с «обычно» резко перескочил на «у нас хайлоад».

пока ты меня не убедил

Тебе как минимум показали 2 кейса. Ну ладно, нет так нет. Иди гуляй, ты ж хотел.

Так себе те кейсы под «обычно» подпадают.

И тебе не хворать.

Так себе те кейсы под «обычно» подпадают

Не, ну для школьного сайта ты можешь что угодно навалять. А так вообще за ORDER BY date_added в нормальных местах увольняют. Тебя и того кто тебя на работу взял.

А ты думаешь, что есть только хайлоад и школьный сайт?

Как хорошо, что я с тобой не в одной реальности.

Допустим с ключом от 1 до 100 (условно) - данные из пункта А, а от 101 до 300 - из пункта Б

Для таких вещей обычно делают nested set.

NAMES ARE INCOMPARABLE

А ты думаешь, что есть только хайлоад и школьный сайт?

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

костыли работающие через раз

Ты не можешь представить ситуации, когда

ORDER BY date_added

будет работать предсказуемо? Сочувствую.

К примеру подумай в контексте: актор, очередь, событие, операция длящаяся дольше микросекунды, лог... профит.

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

Гарантирует, потому что автоинкремент работает через лок.

Лок, хайлоад, 100500 rpns. Чот орнул прям.

UPD Ага, там ещё и банк!

Допустим с ключом от 1 до 100 (условно) - данные из пункта А, а от 101 до 300 - из пункта Б

Для таких вещей обычно делают nested set.

Кстати, я вспомнил откуда это у меня в голове. Я так делал. Правда там и БД была не реляционная, и синхронизация данных через дискету с курьером ФАПСИ.

Ага, там ещё и банк!

Хороший банк, клиентов много.

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

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

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

Банк, не банк это дело десятое. Потом после таких вот «индусов» боинги падают. Потому что «ну это же никогда не случится». Даже как-то странно что приходится такие вещи объяснять.

PS: ещё более странно, что кто-то думает, что примеры взяты из моей жизни. Аллё, примеры специально утрированы в дидактических целях.

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

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

Что если логика не допускает двух записей в одно время, кого увольнять тогда?

Что значит не допускает? У тебя два события произошли в одно время. Что ты собираешься делать? Выбросить одно? Чуть-чуть подождать и молиться чтобы в эту наносекудну ничего не прилетело ещё? Хватит уже мучать жопу и защищать некорректное решение путём нагораживания костылей на костыли.

если порядок двух записей в одну микросекунду не важен

Он всегда важен. Без этого ты не сможешь перебирать записи по страницам. Что если тебе нужно не первые 10, а вторые 10? Если порядок не установлен, то и в первой и во второй странице БД тебе может отдать одну и туже запись, и т.о. одну запись при переборе ты пропустишь.

Да блин, ты серьёзно?

Есть актор, у него очередь задач, задача выполняется несколько минут, по факту выполнения записывается лог. Последние записи того лога на клиент отдаются c тем самым order_by: :created_at.

Вопрос: какие звёзды должны вызвать ошибку?

Он всегда важен

да_ладно.jpg

Уже даже не смешно.

задача выполняется несколько минут

Какая разница сколько времени выполняется задача? Важно что задачи могут «записываться в лог» одновременно.

А если не могут, то это какое-то очень узкоспециальное немасштабируемое решение, где нагрузка не может меняться и всё рассчитано по тактам.

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

Важно что задачи могут «записываться в лог» одновременно.

Нет же, не могут, это ОЧЕРЕДЬ.

Что ты такое пишешь, что у тебя такой узкий кругозор?

Нет же, не могут, это ОЧЕРЕДЬ

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

Что ты такое пишешь, что у тебя такой узкий кругозор

Вообще-то у тебя. Ты похоже слаще морковки ничего не пробовал. Но страдаешь от Даннинга-Крюгера по-полной.

Я тебе привожу реальный пример из того над чем сейчас работаю.

Внезапно у очереди может быть (и обычно бывает в реальных системах) несколько воркеров

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

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

Вообще-то у тебя

Прочитай ещё раз всю ветку, я ни разу не сказал что твоя версия неправильна, я пытаюсь донести до тебя, что есть варианты.

Даннинг-Крюгер

;-)

Ты не ответил, каким образом order_by: :created_at может в данном примере вызвать ошибку?

Важно что задачи могут

А если не могут

Классик!

И мне почему-то кажется, что это модно-молодёжно не такая уж редкость.

ergo, не знаешь, много твоим фреймворком людей пользуется?

Akka и OTP точно много.

Из своей практики скажу что не нужно делать, но с чем пришлось столкнуться:

Хранить дату как текст и хранить ее в unix формате или хранить ее в разных форматах в разных таблицах, для этого всего есть просто timestamp with time zone.

Путать boolean и text, банально, но случалось, и проблем от этого потом достаточно.

Делать gunzip, gzip перед тем как грузить данные (обратная совместимость она такая да!)

Писать хитрые портянки со сложением, умножением, переписыванием значений ON CONFLICT, чтобы не делать лишний SELECT, - оно того не стоит. О великий PostgreSQL без UPSERT

Я не знаю, я сто лет не использую MySQL. У MySQL бывали специфические фичи, которых нет у MSSql/Oracle/Postgres (типа агрегата first/last), и не было обычных для MSSql/Oracle/Postgres фич. Такое начинает подбешивать, а учитывая, что даже массовый шаред хостинг даёт базу постгреса за копейки, я на MySQL забил.

без UPSERT

Вы же понимаете, как UPSERT на большой базе тормозит! Да даже обычный insert.

А да еще, раз уже начал, только что вспомнил.

Не стоит писать длинные OUTER JOIN’ы или вообще если у тебя уже не лезит в латинский алфавит для названия это всего добра, а то потом будешь искать что такое aq например, ну и так далее, ну или сразу выбирай более точные название, ведь никто не знает как оно разрастется в будущем. Да и вообще, конечно чем короче, проще и понятнее, тем лучше когда ты будешь потом это читать.

Удобства все-таки не хватает, к альтернативам привыкаешь, но все равно это все неудобно.

Ну, если скорость не критична, можно функцию написать. Можно триггеры...

В моей области (BI) основной insert - это bulk из csv с локом таблицы, поэтому как-то не парит :)

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

Круто, как-нибудь таки доберусь попробовать.

Загуглить аналоги под другие БД сам осилишь?

и в дырки не попали новые пользователи хотя бы вручную?

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

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

Зависит от области. Где-то, в финансах и около того например, необходим KYC/KYB, иногда на уровне законов. В таких случаях перевод пользователя в прод базу можно рассматривать как ручную или полу-ручную операцию, а за каждую вошь тебя поблагодарит аудитор.