Я планирую базу данных для хранения большого количества текста. (сообщения в блогах, новостные статьи и т. д.) В базе данных должны быть поля заголовка, содержимого (не более 50 000 символов), даты, ссылки и языка. Один и тот же контент не может встречаться по одной ссылке. Старый контент (например, старше 30 дней) будет удален.

Теперь проблема является первичным ключом. Я мог бы просто установить автоматически увеличивающееся поле (тип SERIAL) и использовать его в качестве первичного ключа. Но это кажется глупым и пустой тратой дискового пространства, потому что поле не будет служить какой-либо цели, кроме как быть первичным ключом. (и поле может в конечном итоге закончиться, или нет?) И всегда есть другая проблема с производительностью: содержимое каждой новой вставленной строки необходимо проверять на наличие дубликатов. Таким образом, другое решение для первичного ключа, который я придумал, состоит в том, чтобы вычислить хэш sha256 для содержимого + значение ссылки, а затем поместить его в новый хэш. столбец и использовать его в качестве первичного ключа. Две птицы с одним камнем. Конечно, проблема в том, что это хеш-коллизии. Это большая угроза?

У меня нет никакого опыта работы с PostgreSQL и очень мало опыта работы с СУБД в целом, поэтому я был бы признателен за второе мнение перед созданием базы данных с характеристиками производительности улитки на шоссе (ужасное сравнение).

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