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

Question

У меня есть таблица с двумя столбцами varchar (Max)

Column 1      Column 2
-----------------------
URLRewitten   OriginalURL

это часть моего переписывания URL для сайта веб-форм asp.net.

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

У меня вопрос: если все, что я делаю, это запрос таблицы для URL-адресов, и никакая другая таблица в базе данных никогда не будет ссылаться на эту таблицу, нужно ли ей поле выделенного первичного ключа? как авто-номер? это сделает запросы быстрее?

а также как я могу сделать запрос более быстрым?

Редактировать: у меня есть уникальное ограничение на URLRewitten.

Редактировать: способы, которыми я использую эту таблицу ..

• Запрос при поступлении нового запроса .. выполните поиск по URLRewitten, чтобы найти OriginalURL
• Когда необходимо отобразить ссылку на сайте, я запрашиваю у OriginalURL URL-адрес URLRewitten, который должен использовать.
• При добавлении нового URL в таблицу я удостоверяюсь, что он еще не существует.

это все запросы, которые я делаю .. на данный момент.

Оба столбца вместе будут уникальными.

Answer 1

Вам нужен первичный ключ? Да. Всегда. Однако, похоже, в вашем случае OriginalURL может быть вашим первичным ключом (я предполагаю, что для заданного значения в OriginalURL не будет более одного значения для URLRewritten).

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

Пока что я бы посоветовал создать две вещи:

1. Первичный ключ в вашей таблице столбца идентификации
2. Уникальное ограничение на OriginalURL для обеспечения целостности данных.

Answer 2

В любом случае, я бы поместил туда один ... это упростит обновление или дублирует существующее правило ...

т.е. это проще

UPDATE Rules SET OriginalURL = 'http://www.domain.com' WHERE ID = 1

--OR

INSERT INTO Rules SELECT OriginalUrl, NewUrl FROM Rules WHERE ID = 1

Чем это

это проще

UPDATE Rules SET OriginalURL = "http://www.domain.com" WHERE OriginalURL = 'http://old.domain.com'

--OR

INSERT INTO Rules SELECT OriginalUrl, NewUrl FROM Rules WHERE OriginalURL = 'http://old.domain.com'

С точки зрения производительности, если вы собираетесь искать в OriginalURL, Вы должны добавить индекс к этому столбцу,

Answer 3

Я бы использовал OriginalURL в качестве первичного ключа, так как предположил бы, что он уникален. Предполагая, что вы используете SQL-Server, вы можете создать индекс для RewrittenURL с OrigionalURL в качестве «включенного столбца» для ускорения выполнения запроса.

Answer 4

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

Есть ли у вас индекс в вашем столбце перезаписи URL? Если нет, создайте его: это должно значительно увеличить скорость ваших запросов (возможно, просто сделать URL перезаписать ваш первичный ключ?).

Answer 5

Столбец идентификации может помочь при поиске последних событий:

select top 100 * from table order by idcolumn desc

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

Answer 6

Да, должен быть первичный ключ, потому что вы можете установить INDEX для этого первичного ключа для быстрого доступа

Answer 7

Я не думаю, что добавление автоматически сгенерированного первичного ключа сделает ваш запрос быстрее.

Однако есть несколько вещей, которые следует учитывать:

1. Я бы не был так уверен, что никогда никогда ничего не будет ссылаться на эту таблицу :(.
2. Я видел много людей, спрашивающих о как удалить дубликаты из таблица такая - с первичным ключом это намного проще
3. Чтобы сделать этот запрос быстрее нам нужно узнать больше об этой таблице и способах использования его ...

По моему мнению, каждая таблица должна иметь автоматически сгенерированный первичный ключ (т. Е. Идентификатор в MSSQL).

Я не верю в уникальные природные ключи.