Как разбить таблицы?

Question

[Maksim Drazdou]

Сервис по бронированию экскурсий, экскурсия привязывается к региону и одна экскурсия может быть привязана к нескольким регионам. В каждом регионе есть свой список отелей из которых забирают клиентов и везут на экскурсию
Таблицы:

1) regions - id, title
    2) excursions - id, title, text
    2) hotels - id, title

Как разбить таблицы, чтобы поиск был либо по региону, либо по региону и отелю к нему привязанному?
Например:

1) excursion_region - id, excursion_id, region_id
    2) excursion_region_hotel - id, excursion_region_id, hotel_id

Comments

[Vitsliputsli]

У вас даже в описании указано, что отель должен быть привязан к региону. И уж точно не к таблице связей.
Ну и на всяк случай, вместо hotel можно использовать start_location, если вдруг не только в отелях начнут людей собирать.

[mayton2019]

У тебя топик тегирован Postgres. Вот пиши сразу DDL скрипты. У тебя должно быть 3 создания таблиц.

create table reg...
create table excu..
create table hotel...

И несколько созданий ссылочных констрейнтов.

ALTER TABLE ....
      ADD CONSTRAINT .... FOREIGN KEY (...)  REFERENCES .....

Вот готовый шаблон.

А вот такую неизвестную лабуду писать не надо.
excursion_region - id, excursion_id, region_id
Из нее ничего невозможно почерпнуть. Ни тип связи. Ни направление связи.

[Jack444]

Если у тебя title это уникальное поле в рамках таблицы, то лучше сделай его первичным ключом, так существенно снизишь количество подзапросов, поля которые ссылаются на первичный ключ проиндексируй.
Как вариант в таблицу excursion_region можно добавить колонку ARRAY и туда закидывать отели, на эту колонку GIN индекс нужно повесить.

[Vitsliputsli]

Вопрос суррогатный vs натуральный ключ сложный, но в большинстве случаев лучше выбрать именно суррогатный. К примеру, если сделать натуральный ключ для регионов по его 2-3 буквенному ISO коду - отлично, а вот делать натуральный ключ по названию отеля очень сомнительный выбор, мало того что название может поменяться, так еще и делать ключ придется очень длинным и надеяться, что все названия в него поместятся, а потом еще и ссылки на него делать такими же. И скорее всего никто не будет искать по полному названию отеля, и тогда плюсы его как кластеризованного индекса сходят на нет.
Array, json и т.п. - это как правило нарушение нормализации, делать так нужно только тогда, когда понимаешь, что плюсы перевесят минусы. Т.е. в большинстве стандартных ситуаций это тоже не нужно.

Answer 1

[Константин Цветков]

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

Никак. Таблицы нужно связывать (JOIN).

Отель не может перемещаться. То есть Регион — это поле в таблице Отель.

У вас нет главной таблицы: План экскурсии с полями: Экскурсия, Дата, Отель.

SELECT *
  FROM План экскурсии
    JOIN Экскурсия 
    JOIN Отель
    JOIN Регион
  WHERE