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

Question

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

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

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

код php похож на время (). ранд (1000,9999). $ Pc_id

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

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

Привет

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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