могут быть не уникальны, но комбинация значений этих трёх колонок уникальна. Вопрос:
1) Я могу сделать колонку ID - primary key, простой инкримент. А на эти 3 повесить Unique constraint
2) Могу сделать составной Primary key на эти 3 колонки.
Как правильно будет сделать? По логике/производительности.
Сложно сказать редкие ли инсерты, но апдейты и селекты гораздо чаще. Одну из этих 3ёх колонок хочу индексировать, так как по ней часто идут селекты
Напиши не рандомный, а последовательный генератор данных и посмотри на количествах 100000-500000 записей
Есть дополнительные вопросы: 1) Будут ли у этой таблицы подчиненные таблицы? 2) будут ли апдейты затрагивать значения этих 3 полей, комбинация которых уникальна?
1) По идеи нет, её только будут джоинить 2) Нет, они по сути ключ - если один раз занеслась комбинация, то обновляются только другие поля, относящиеся к этой комбинации
Если есть 100% уверенность в том, что у этой таблицы не будет подчиненных таблиц, и структура таблицы не будет меняться (а это очень смелые предположения), то можно все три поля ввести в первичный ключ. Если же есть сомнения, то лучше все же создать синтетический ключ в виде автоикрементного ID, а на те три поля наложить индекс unique
Никто не мешает потом синтетический unique-констрейнт на вновь добавленном автоинкрементном поде добавить. Гораздо более важна такая штука: могут ли у трёх вышеобозначенных полей быть null-овые значения? Если да, то во-первых, вариант с составным primary key отпадает, а во-вторых, возможно надо будет строить уникальный индекс на с coalesce, т.к. null в любом из полей приводит к игнорированию дублей по двум другим полям.
В 14 если не ошибаюсь это можно побороть, явно указав как интерпретировать NULL
Что-то я сходу в документации не нашел, есть только разные варианты match-ей для foreign key. Не подскажете более конкретно синтаксическую конструкцию или ссылку на доку?
Я видел такое только в доках к бете 15-й версии: https://www.postgresql.org/docs/15/ddl-constraints.html Конструкция unique nulls distinct/not distinct
да, вы правы - это я напутал, оно в было в бете к 15
Обсуждают сегодня