Как представить набор сущностей из отдельных таблиц?

Question

У меня есть несколько таблиц, представляющих географические объекты (CITIES, COUNTIES, ZIPCODES, STATES, COUNTRIES и т. Д.).

Мне необходимо представить наборы географических объектов. Набор может содержать записи из более чем одной таблицы. Например, один набор может содержать 3 записи из CITIES, 1 запись из COUNTIES и 4 из COUNTRIES.

Вот два возможных решения:

• Таблица, которая содержит три столбца - по одной записи для каждого объекта. Таблица будет содержать несколько записей для каждого набора, все разделяют номер набора.

set_id INT, foreign_table VARTEXT(255), foreign_id INT

Примеры записей для набора № 5:

(5,'CITIES',4)

(5,'CITIES',12)

(5,'ZIPCODES',91)

(5,'ZIPCODES',92)

(5,'COUNTRIES',15)

• Таблица, которая содержит столбец TEXT для каждого типа сущности, который будет включать строку, содержащую соответствующие записи:

set_id INT,cities TEXT,counties TEXT,zipcodes TEXT,states TEXT,countries TEXT

Таким образом, вышеуказанный набор будет представлен одной записью

(5,'4,12','','91,92','','15')

Есть еще идеи? Хотелось бы услышать ваш вклад. Спасибо!

Answer 1

• Один Location Set может иметь много Geography предметов
• Один Geography элемент может принадлежать многим Location Sets

Что касается таблицы элементов Geography, возможны два подхода. В первом случае отношение супертип / подтип перекрывается - более одного подтипа может быть связано с супертипом. Например, в таблицах Geography и Zipcodes, Cities, States, Countries могут быть GeographyID = 5.

Во втором случае мы можем рассмотреть исключительные (непересекающиеся) отношения, в которых только один подтип может быть связан с супертипом. Родительско-дочерние отношения используются для создания путей, например ZIP/City/State/Country - то есть, если фактические административные области допускают этот тип отношений.

В этом примере в Geography может быть GeographyID = 5 и только одна таблица подтипов.

Answer 2

Оба решения, которые вы предлагаете, не имеют реальных внешних ключей. В первом решении один foreign_id может указывать на множество таблиц, что трудно (или, по крайней мере, неэффективно) для принудительного применения базы данных. Второе решение хранит несколько значений в одном столбце, и это то, что все соглашаются с тем, что вам не следует делать это (оно нарушает первую нормальную форму .)

Я бы сделал следующее: города, почтовые индексы и штаты имеют географическое положение. Обычный способ реализовать это - отношение один ко многим. Создайте таблицу геолокации и добавьте столбец geolocation_id к городам, почтовому индексу и таблицам состояний.

РЕДАКТИРОВАТЬ: Для вашего комментария, чтобы добраться от геолокации в свои города:

select    *
from      geolocation g
left join cities c
on        g.id = c.geolocation_id
left join zipcodes z
on        g.id = z.geolocation_id
....

База данных будет разрешать объединения с использованием индекса внешнего ключа, что очень быстро.