Таблица показателей производительности.варианты выбора первичного ключа - PullRequest
1 голос
/ 16 ноября 2011

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

TBL_A
{
 'A1' varchar (64), // assume this is the unique attribute.
 'A2' varchar (64),
}

TBL_B
{
 'B1' varchar (64), // assume this is the unique attribute.
 'B2' varchar (64),
}

TBL_C
{
 'C1' varchar (64), // assume this is the unique attribute.
 'C2' varchar (64),
}

Отношения:

  • между TBL_A и TBL_B как многие ко многим,
  • между TBL_AB и TBL_C от ОДИН до МНОГО

вопросы:

  1. какой из них лучше: ОПЦИЯ A: установить уникальный атрибут каждой таблицы в качестве первичного ключа таблицы? или ОПЦИЯ B: создайте другой атрибут, который будет идентификатором (автоматический номер), и установите уникальный атрибут таблицы с уникальным ограничением. (будет применяться ко всем этим трем таблицам).

  2. тогда TBL_AB необходимо будет скопировать первичный ключ из TBL_A и TBL_B в качестве ссылочного ключа. вопрос снова похож на мой предыдущий, должны ли мы оставить эти два ссылочных ключа первичным ключом TBL_AB? или гораздо лучше создать новый уникальный атрибут (автоматический номер), который будет первичным ключом TBL_AB, и сделать два ссылочных атрибута с уникальным ограничением.?

  3. , поскольку od TBL_C будет ссылаться на первичный ключ TBL_AB, конечно, вступит в силу опция, которую мы выбрали в двух предыдущих вопросах. Если мы выберем первый вариант, будет два атрибута, на которые есть ссылки, но если мы выберем второй вариант, у нас будет только один атрибут, на который есть ссылки. как ты думаешь.?

идея в том, что когда мы находимся в ситуации поиска, запрос первичного ключа целочисленного (или числового) типа будет выполняться быстрее, чем первичного ключа типа varchar,? какой из них лучше,.? и, конечно, если у вас есть «почему»,

спасибо за каждый ответ и предложение. С уважением,

1 Ответ

1 голос
/ 16 ноября 2011

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

...