Альтернатива для составного ключа

Question

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

для примера Таблица Автор имеет два столбца, таких как AutherId, который является номером автоматического увеличения и pc_id, который является уникальным для этого ПК, которые являются составными ключами для таблицы. но когда дело доходит до отношений, я должен определить оба столбца для каждого отношения. и поскольку я планирую использовать Docrtine (PHP ORM), это бит проблематично использовать его так.

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

php-код похож на time(). rand (1000,9999). $ pc_id

так, чтобы идентификатор генерировался путем конкатенации + случайного числа между 1000 и 9999 и pc_id (pc_id также является числом, начинающимся с 1). но это делает 20-значный номер (когда pc_id 6 цифр), которая нуждается в BIGINT для хранения

есть хороший вариант для этого

С уважением

Answer 1

В таблице автор только нужен один первичный ключ - AuthorID , Почему у вас будет два автора с одинаковым идентификатором? Если у вас много отношения к автору, то есть отдельная таблица pc с первичным ключом PcId и поле AuthorId.

Answer 2

Часто считается, что БД автоматически генерирует первичный ключ вместо использования бизнес-информации для этой цели.

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

Так я говорю, генерировать первичный ключ, и получить уникальное ограничение на ваш бизнес ценности

Answer 3

Вы можете использовать UUID в качестве суррогатного ключа. Он глобально уникален для всех серверов. Недостатком является то, что это 36-байтная строка, которая может быть громоздкой, чтобы проходить вручную.

Если вы можете встретить условия, то есть uuid_short(), что представляет собой 64-битное целочисленное представление UUID, но у него есть определенные ограничения на то, как/когда его можно считать глобально уникальным, так как он упускает половину 128-битных символов UUID поэтому он может втиснуться в поле «bigint unsigned».