TL;DR; використовуйте nanoid
Сьогодні поговоримо про формат первинного ключа. Почнемо з типового порівняння id VS uuid.
id, інкрементний ключ, тобто 1, 2, 3, ...
➕ простий у роботі
➕ по ньому можна сортувати
➖ Не є String. Нагадаю, що id входить до URL, який є String.
➖ Легко створити колізію. Приклад із практики: до міграції додано admin c id=1000. Це пішло у реліз.
➖ Створюють ризики для системи – її просто аналізувати: скільки сутностей, як швидко вони додаються
➖ сутності не можна переносити між оточеннями (типова проблема самописних CMS)
uuid, приклад
1FE577FE-9AED-4728-8B88-AAA11FA11E76➕ гарантовано унікальні
➕ можна генерувати будь-де, а не тільки в БД. Нагадаю про crypto.randomUUID() і браузер, і в Node.js.
➖ довгі, тобто потрібно більше місця, щоб зберігати та передавати
➖ Людям із ними не так зручно працювати
➖ Сортування за таким ключем не має сенсу
Хорошою альтернативою uuid є nanoid. Приклад,
V1StGXR8_Z5jdHi6B-myT. Ще він дозволяє вибрати довжину та алфавіт. Тому його часто використовують у web додатках.Посилання по nanoid:
🔗 https://www.npmjs.com/package/nanoid
🔗 https://github.com/Jakeii/nanoid-postgres
🔗 https://zelark.github.io/nano-id-cc/