Использование пользовательской схемы кодификации вместо GUID в качестве первичного ключа

Question

Я использую базу данных MS Access для SQL Server. Внешний клиент пока останется приложением Access (около 30 тыс. Строк кода).

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

Я спрашиваю не о процессе увеличения, а о том, должен ли я использовать GUID или другую кодификацию для PK (я знаю, что могу разделить диапазон номеров по серверам, но я не хочу этого делать и разрешать PK, который необходимо создать на клиенте, если необходимо, например, в автономном режиме).

GUID

Pro:

• стандартизированный формат.
• уникальность гарантирована (практически в любом случае)

Минусы:

• не легко манипулировать в Access, особенно при использовании их в качестве фильтров для подчиненных форм или в элементах управления.
• ухудшает производительность INSERT из-за их случайности.
• имеет более одного представления: строка, каноническая форма, двоичный файл, который необходимо преобразовать.

Пользовательская схема кодификации

Я подумал, что, возможно, схема, использующая более унифицированный код в качестве PK, позволит избежать снижения производительности и, что наиболее важно, обеспечить, чтобы PK оставался пригодным для использования в элементах управления формой, где это необходимо (и не требовал этих преобразований в / из строки).

Моя идея для схемы кодификации была бы в виде кода из 10 символов, разбитого на:

• 8 цифр для отметки времени
• 4 цифры для уникального идентификатора клиента
• 2 цифры как случайное число для потенциальных коллизий Каждая цифра должна быть в базе 34, состоящей из букв AZ и 2-9, избегая O, 0, 1, I из-за их сходства (в случае, если нам нужно вручную обработать эти PK, для экземпляр во время отладки).

Pro:

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

Минусы:

• производительность в JOIN не доказана
• производительность в INSERT должна быть выше, чем у GUID, но это не доказано
• Каждый сервер / клиентский компьютер должен иметь свой собственный UID, хотя это не должно быть слишком большой проблемой.

Итак, я должен использовать GUID или другую схему для моего ПК?

Answer 1

непросто манипулировать в Access, особенно при использовании их в качестве фильтров для подчиненных объектов или элементов управления.

-> У доступа есть GUID как номер-> Идентификатор репликации. У нас есть приложение в Access с каждым PK в качестве GUID, и у нас нет проблем с фильтрами (и с фильтрами для подфреймов).

ухудшают производительность INSERT из-за их случайности.

-> Если у вас есть проблемы с производительностью, связанные с этим, у вас может быть кластерный индекс для другого столбца (например, отметка времени). Но MSSQL-сервер имеет две функции для генерации новых значений GUID - «newid ()» и «newsequenceid ()». Второй метод, как следует из названия, генерирует новые значения в последовательности, поэтому проблема производительности вставки не должна возникать.

имеет более одного представления: строка, каноническая форма, двоичный файл, который необходимо преобразовать.

-> это "PRO" на мой взгляд :). Но для пользователей-разработчиков и пользователей-администраторов в Access и MSSQL представлены и используются в виде строки ..

GUID находится в основном "только" 128-битном номере. Я не думаю, что вам следует беспокоиться об эффективности соединений на столбцах GUID. Например, объединение столбцов GUID гораздо эффективнее, чем условия для текстовых столбцов.

Я не думаю, что нестандартная схема кодификации - это хорошая идея, потому что вы должны решить многие вопросы. С другой стороны, GUID используется стандартно, и инструменты готовы к его использованию.

Answer 2

Сколько записей вы планируете? Бигинт не достаточно большой? До 9 223 372 036 854 775 807 записей (если не включить негативы)

Если это только для вставок, а выбор не для данных, используйте любую схему (я бы сказал, bigint или GUID / uniqueidentifier). Если вам нужно сделать выбор, int или bigint намного быстрее, чем GUID или любой другой пользовательский PK.