Order By почему бы не PK просто вместо created_at?

[AnrDaemon]

Про перевод времени система в курсе. От тебя требуется только знать, что он возможен, и работать с датами как с датами, а не [цензура] знает с чем.

 

[antson]

Вот если отвлечься от вопроса, что быстрее и задуматься а зачем вообще нужен строгий порядок регистрации записей в порядке поступления?

Я сейчас могу вспомнить только задачи "типа продажи билетов / номеров / доменов / голландских аукционов ",
но их имхо правильней решать не порядком следования записей, а флагом "товар продан"

телеметрия , так по фиг как она лежит, тут привязка к времени самого прибора должна быть

Насчет автоинкрементного ид :
1) случаи более одного сервера данных
2) они заканчиваются (особенно быстро при использование insert-or-update)

хотя , в начале звучало, что его будет присваивать диспетчер очереди.

 

[fixxxer]

А для построения частичных индексов постгресом тоже не влияет? (create index ... where deleted_at is null)

С частичным я так делаю даже не поэтому (удаленных всегда мало, так что не принципиально), а для уникальности только по неудаленным. Скажем, удалился пользователь с данным емейлом, через год решил заново зарегистрироваться. При unique(email) where deleted_at is null никаких проблем и плясок.

В mariadb, кстати, это можно изобразить с минимумом накладных расходов через virtual columns, как-то так:

CREATE TABLE users ... (
_null_if_deleted char(0) AS (IF(is_deleted, NULL, '')) PERSISTENT,
UNIQUE (email, _null_if_deleted)
);