Использование хеша одновремено с Id

[an.viktory@gmail.com]

Задача:
1. Не дать любопытным попытаться проанализировать структуру приложения (по id часто можно определить кол-во пользователей, статей и пр.).
2. Отвязаться от глобального автоинкремента. Ну т.е. если например статьи пользователей лежат в базе posts то список post_id статей пользователя может выглядеть вот так 3,56,765 согласно выданному при вставке id и для конкретного пользователя которому не нужно знать о существовании других статей это лишняя путаница. было бы логичнее иметь 1,2,3 в рамках одного пользователя.
3. Предполагается, что данные в системе будут закрытые от других т.е. два разных пользователя не могут искать записи без своего user_id.
4. Google активно использует hash в своих сервисах youtube , docs пр. т.е. в качестве публичного уникального поля для поиска использует hash .
Варианты решения:
users : id|username|......|user_hash
posts: id|body|hash|current_number|user_hash
таких образом если мне например надо послать запрос от клиента на сервер, то буду искать where user_hash = "slsjflasjlajsf", current_number всегда будет приближен к реалиям в рамках одного пользователя ( это поле не для сортировки, а для id но в рамках одного пользователя).
Получается, что я могу в качестве параметров на фронте для запросов на сервер использовать hash. т.е. задача вроде как решается.
Возможные проблемы:
1. Использование hash для поиска по базе замедлит запросы и увеличит нагрузку на базу.
2. (предвосхищая вопрос при чем тут YII??) Есть ли готовые решения- поведения для AR для выдачи hash, определения оптимальной длины хеша для максимального количества пользователей и пр. Как AR будет воспринимать связи по hash (естественно в плане скорости если вдруг база разрастется ну например до нескольких миллинов записей) ? или связи делать по id предварительно найдя этот id по хешу (уже два запроса к базе или вложенный запрос) ?

[kar-slo]

используйте guid вместо id, например.

[an.viktory@gmail.com]

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

[kar-slo]

Ваш hash по сути уже что-то похожее на guid, не понимаю только зачем вам второе поле, если есть стандартное решение замены id(int) на guid. По скорости, да, поиск будет несколько медленнее чем по int(в основном из-за сортировки индекса), но не особо критично. Многие очень крупные проекты используют гуиды.

[an.viktory@gmail.com]

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

[kar-slo]

то о чем вы говорите, правильнее назвать текстовый идентификатор. GUID - это определенный стандарт. https://ru.wikipedia.org/wiki/GUID
вот статья на хабре про идентификаторы Youtube в том числе с примерами https://habr.com/ru/post/334994/ может быть что-то почерпнете.