Перспективный дизайн первичного ключа в postgresql

Question

Я всегда использовал либо auto_generated, либо Sequence в прошлом для своих первичных ключей. С текущей системой, над которой я работаю, есть возможность в конечном итоге разделить данные, что никогда не было требованием в прошлом. Зная, что в будущем мне может понадобиться разделить данные, есть ли какое-то преимущество использования UUID для PK вместо встроенных последовательностей базы данных? Если да, существует ли шаблон проектирования, который может безопасно генерировать относительно короткие ключи (скажем, 6 символов вместо обычного длинного e6709870-5cbc-11df-a08a-0800200c9a66)? 36 ^ 6 ключей на таблицу более чем достаточно для любой таблицы, которую я могу себе представить.

Я буду использовать ключи в URL, поэтому важна краткость.

Answer 1

Я не уверен, какой тип раздела вы планируете ( это? ), но я не понимаю, зачем менять дизайн первичного ключа? Даже если старые многораздельные таблицы «живы» (т. Е. Вы можете вставить строки в любую многораздельную таблицу), в нет проблем с разделением последовательности между несколькими таблицами.

Answer 2

Нет шаблона для уменьшения 128-битного UUID до 6 символов, так как информация теряется. Почти во всех базах данных реализована стратегия суррогатных ключей, называемая инкрементными ключами. Postgres и Informix имеют серийные номера, MySql auto_increment, а Oracle предлагает генераторы последовательностей. В вашем случае я думаю, что было бы безопасно использовать целочисленные идентификаторы.

См. Эту статью: Выбор первичного ключа: естественный или суррогатный? для обсуждения доступных методов