Зачем, когда есть uuid ?

Для сортировки uuid v1 нужно вытаскивать дату из uuid, что не дёшево

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

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

А почему не создать поле created_at, куда писать now()? По нему и делать сортировку

Получится два поля. Одно uuid, второе timestamp

Это плохо?

В основном, воображаемый. ;) Т.е. так же, как sequence и now(), с каким-либо порядком это может иметь мало общего.

Не в моей ситуации.

Очень повезло, значит. Тогда либо Вам либо хватит временной метки, либо всё-таки и в Вашей ситуации, нет? ;)

Да нет, но это лишняя сложность. Например, в системе должны быть методы get_before_id() и get_after_id() - получится, что тоже усложнение

Ну Вы серьёзно?)

Не нужно быть Вангой, пожалуйста

Что не так?

Никакой же сложности нет. Если Вам нужно отсортировать в порядке добавления, просто вызываете ORDER BY created_at. Какие же тут могут быть проблемы?

Нужно быть реалистом, пожалуйста. ;) Вы понимаете, что тут в самом деле либо одно, либо другое?

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

Очень приближённо: WHERE created_at>(select created_at from mytable where id='dssd') order by created_at ASC limit 100

Ахахахахах

Не более смешно, чем "лишняя колонка в базе"

То есть мы будем думать, что timestamp уникален и делать такое, вместо where id>$1 limit 100?

воспользуйтесь bigint колонкой

Вот. Мой вопрос про это. Кто-нибудь пробовал использовать в реальной жизни генератор из статьи? Смущает, что твиттер от этого отказался и кроме статьи 2012 года нет других примеров из жизни

вам ответили то, как люди поступают в реальной жизни, вас это по каким-то причинам не устраивает.

Он точен до микросекунд (https://www.postgresql.org/docs/10/datatype-datetime.html). Какова вероятность попасть в коллизию?

в транзакции вставить несколько строчек, now() даст время начала транзакции для всех

А, ну так да

А если он не уникален, то "Не в моей ситуации." было тем более неверно... т.е. Вы этот порядок просто "придумываете", и стоит отдавать себе в этом отчёт, вот что я имел в виду. Опять-таки, вера в то, что now() имеет какое-то отношение к порядку транзакций, просто наивна. ;)

Причём тут now()? Ты точно мне ответить хотел?

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

Причём тут now()?

Вот при этом: https://t.me/pgsql/277323 И вот этом: https://t.me/pgsql/277307 И этом: https://t.me/pgsql/277299 Т.е. Вы, похоже, думаете, что реальное время связано с порядком добавления. Если это в Вашем случае так, мне интересно, почему.

Сервис хранения информации получает по rpc данные. В ответ отдаётся id. Далее данные трансформируются, часть уходит в postgresql, вторая часть в другое место. В postgresql нужно будет сортировать данные в порядке получения id (в порядке создания, сохранения), получать строки до и после id. Что не так? Причём тут now? Мой вопрос про хранение и сортировку информации. Кто-нибудь имел опыт с такими id в postgresql? Возможно, какие-нибудь минусы всплыли

С какими “такими”? Вы имеете в виду какую-то конкретную “такую” реализацию или мы сейчас думаем о том, как “такое” реализовать?

Походу, мне тоже нужно что-то употребить. https://t.me/pgsql/277296

> Сервис хранения информации получает по rpc данные. В ответ отдаётся id. Так, а при чём тут тогда были генераторы? > В postgresql нужно будет сортировать данные в порядке получения id Тогда порядок "создания, сохранения" не имеет никакого отношения к делу, нет? Т.е. Вам просто нужны сортируемые id, которые Вы будете сохранять и использовать, вот и всё. > Причём тут now? Ни при чём, казалось бы. Как и порядок появления данных в базе. Т.е. делаете сортируемые id и верите им, и всё, разве нет? > Кто-нибудь имел опыт с такими id в postgresql? Возможно, какие-нибудь минусы всплыли И всё равно непонятно, какие тут могут быть минусы. Хоть из PostgreSQL-овской sequence или её аналога выдаёте эти id, да и всё.

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

А как это будет связано с сортировкой? В общем, задачу я так и не понял. :(

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

С точки зрения клиента - rpc сервис и есть база