Короче (если получится):
В настоящее время, для обеспечения уникальности неких “элементов”, хранимых в базе данных, используется uuid V4.
И всё бы ничего, но, предполагается генерация этих uuid на разных инстансах. Что, не теоретически, а практически, точно приведёт к коллизиям (генерации разными инстансами одинаковых значений). Чтобы эти инстансы не зависили от некоего единственного провайдера uuid’ов, который в состоянии проверять, выдавал ли он ранее такой uuid или нет, появилась идея использовать “пространства имён” на основе даты и времени создания нового “элемента”.
Вообще, понятно, что в самой таблице, хранящей данные “элементов”, присутствует автоинкрементное поле “id”, которое эту уникальность, конечно же, обеспечивает. Но вот беда, некоторые приложения, пользующиеся этими данными, не используют автоинкрементные айдишники, а используют выше обозначеный uuid V4. Засим, дабы не патчить эти приложения, вместо uuid V4 им можно подсунуть строковый уникальный идентификатор, о котором ниже:
Я хочу генерировать уникальные ключи вида (без квадратных скобок, они тут только для того, чтобы вам было понятно из чего состоит ключ):
[year][month][day][hour][min][sec][usec][usec][usec]
Где:
year – год, всегда 4 цифры
month – месяц в году, всегда 2 цифры
day – день, всегда 2 цифры
hour – текущий час, всегда 2 цифры
min – текущие минуты, всегда 2 цифры
sec – текущие секунды, всегда 2 цифры
usec – текущие микросекунды, всегда 6 цифр, три раза по 6
Теперь подробнее про микросекунды:
Тики процессора, в принципе, по частоте их следования, сопоставимы с его тактовой частотой и значениями микросекунд. Кроме того, процессор, как правило, выполняет несколько задач, циклически обходя каждую из них, и, возвращаясь к задаче генерации ключа, эта задача, трижды запрашивающая текущее значение микросекунд, будет получать немного отличающиеся значения (уже проверено). Ну а три раза подряд – это и есть защита от коллизий в пределах одной секунды, ещё и на разных инстансах.
Так вот вопрос:
Насколько по вашему подход, выбранный мной, будет надёжным? Конечно же, учитывая генерацию на разных инстансах.
А как ты вообще клиентов добавляешь? У тебя совсем открытый сервис, никаких API ключей?
Даже если будет у каждого свой, то авторизация никак не связана с данными в базе. Проблема в том, что все эти клиенты используют данные из одной базы, но ууиды для этих данных у этих клиентов у каждого свои. Отсюда возникают коллизии и на стороне базы и на стороне клиентов, т.к. каждый клиент мерджит данные, отправляет свои новые в базу и получает чужие (других клиентов) из базы. Клиенту можно скормить в ответе (в другом пересылаемом в обе стороны поле) ключи, уникальные для всей базы, а соответственно, уникальные и для всех клиентов. Клиент может сопоставить свой, коллизный к внешним, но уникальный у него, ууид и этот ключ для какой-то записи. Пусть ебется со своими ууидами сам. Дабы обойти коллизии с ууидами, я хочу вообще не цепляться за ууиды клиентов и вообще не хранить их в базе, вместо этого хранить свои уникальные.
Я, правда, до конца не понимаю механизм работы сервиса. Получается, что у тебя все клиенты могут добавлять записи в базу. При этом идентификаторы создаются ими же, а не тобой. И с этими айдишниками кто в лес, кто по дрова. Правильно?
Тогда надо генерить свой и возвращать клиенту в ответ, пусть они там сами ебутся с маппингом.
Если ты можешь заставить клиентов использовать твой айдишник, то генерь его сам тем же UUID генератором, только проинициализируй его правильно.
Если не можешь, то надо городить композитный ключ у себя, при этом нужно будет как-то уникально идентифицировать клиентов.
Именно так.
Они этого не умеют…
Эх… Обрадовал ты меня!