Лучше использовать URL (длинную строку) для первичного ключа или более короткий последовательный целочисленный первичный ключ?

Question

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

Answer 1

Для каких целей вы храните веб-страницы?

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

Answer 2

Еще одна вещь, которую вы можете рассмотреть, это снижение производительности, которое вы получите при использовании строкового поля в JOINS, INDEXES и условиях.Я должен согласиться с @dclelements и @Neil в рекомендации целочисленного поля PK.

Другими соображениями являются невозможность автоматического увеличения значений PK для URL-адресов, поэтому вам придется обрабатывать (более высокую вероятность) повторяющихся вставок в таблицу.

Целочисленное значение для PK лучше для проектирования базы данных.

Answer 3

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

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