Альтернатива составному ключу

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

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

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

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

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

есть хорошая альтернатива этому

С Уважением


mysql php primary-key composite-key
person Chathura86    schedule 26.04.2010    source источник
comment
я не могу использовать автоматическое создание первичного ключа, потому что эта база данных будет работать на разных компьютерах (разные pc_id), а позже все данные будут переданы в одну общую базу данных, так что если бы я сохранил только автоматически сгенерированный ключ в качестве первичного ключа то он будет продублирован   -  person Chathura86    schedule 26.04.2010

Ответы (3)


arrow_upward
2
arrow_downward

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

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

Поэтому я говорю: сгенерируйте первичный ключ и получите уникальное ограничение для ваших бизнес-ценностей.

person Hendrik    schedule 26.04.2010
comment
я не могу использовать автоматическое создание первичного ключа, потому что эта база данных будет работать на разных компьютерах (разные pc_id), а позже все данные будут переданы в одну общую базу данных, так что если бы я сохранил только автоматически сгенерированный ключ в качестве первичного ключа то он будет продублирован. - person Chathura86; 26.04.2010
comment
Это звучит очень интересно. Таким образом, вы просто объедините свой первичный ключ при извлечении его из базы данных. Но как тогда сделать запрос к базе данных с конкатенированным первичным ключом? - person andrew; 25.01.2011

arrow_upward
1
arrow_downward

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

person Skilldrick    schedule 26.04.2010

arrow_upward
0
arrow_downward

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

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

person Marc B    schedule 26.04.2010