PostgreSQL, многоязычная БД, тип первичных ключей?

Question

[noob_bot]

Разрабатываемый мной проект (REST API) разбит на множество модулей. Каждый модуль хранит данные в своей БД. БД некоторых модулей могут содержать таблицы, ссылающиеся на данные других модулей.
Проект должен поддерживать множество языков. Новые языки могут быть добавлены в любое время.
Я выбрал следующую структуру для хранения переводимых сущностей:

CREATE TABLE languages
(
    id UUID NOT NULL PRIMARY KEY,
    code CHAR(2) NOT NULL,
    name TEXT NOT NULL
);
CREATE UNIQUE INDEX languages_code_uindex ON languages (code);

CREATE TABLE countries
(
    id UUID NOT NULL PRIMARY KEY,
    some_property INT
);

CREATE TABLE country_translations
(
    country_id UUID NOT NULL,
    language_id UUID NOT NULL,
    name TEXT NOT NULL,
    
    CONSTRAINT country_translations__pk PRIMARY KEY (language_id, country_id)
);

У меня есть несколько вопросов:

1. Я использую UUID в качестве PK для всех таблиц. Хорошо ли это?
   
   Я выбрал UUID, т.к. в коде REST API использую подход CQRS. Команды не могут возвращать никаких данных => я не могу вернуть Id созданной записи. Поэтому я генерю Guid и передаю его в команду, после чего могу этот Guid вернуть пользователю.
   
   
2. Стоит ли изменить PK у таблицы languages на char(2)? В поле code будет содержаться код языка (ISO-639-1). Этот код будет уникальным -> его можно сделать PK для таблицы Languages.
   

Answer 1

[V Sh.]

Стран как и известных языков в этом мире не так много. Так что даже полный перебор по таблице по первичному GUID ключу в современных БД занимает крохотную часть времени. Сосредоточились бы вы на вещах более серьезных.

Что касается использования GUID для всех таблицы: тут есть свои плюсы и минусы. Минусы связаны с занимаемым местом и производительностью. Плюсы с легким поиском элементов в системе и невозможностью (оооочень малой вероятностью) возникновения коллизий при различных бекапах/деплоях/переездах БД. Весь Microsoft'овский SharePoint на этих GUID'ах работает...

Answer 2

[Александр Аксентьев]

UUID нужен по идее когда нужна супер уникальность и фиксированный вид идентификаторов, вне зависимости от айдишника. Ну и как защита от перебора.

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