Реляционная база данных, фотографии, голоса и предупреждения

Question

Я проектирую реляционную базу данных, но у меня не так много опыта, поэтому я хотел бы спросить предложение о реляционных таблицах с фотографиями.

Я подумал использовать table для хранения photos и одну или несколько таблиц для пользовательских данных и ссылок на темы, чтобы фотографии могли быть связаны с различными темами, например, houses или trees в этом случае я мог бы иметь такую ​​структуру:

table_houses
- house_id
- house_name
- house_architect_name, house_..., etc.

table_trees
- tree_id
- tree_name
- tree_plant_type, tree_..., etc.

table_photos
- photo_id
- photo_filename
- photo_date
- photo_user_id

table_rel_houses
- rel_id
- rel_house_id
- rel_photo_id
- rel_user_id
- rel_vote_id
- rel_warn_id

table_rel_trees
- rel_id
- rel_tree_id
- rel_photo_id
- rel_user_id
- rel_vote_id
- rel_warn_id

table_warns, table_votes, etc.

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

Может ли структура данных быть правильной или я должен разбить гораздо больше реляционной таблицы в table_rel_votes и table_rel_warns?

Мне понадобятся классические страницы с увеличенной фотографией и миниатюрами для навигации по другим, я должен учитывать, что структура может хранить много миллионов строк фотографий.

Answer 1

Вы можете рассмотреть возможность моделирования вашей базы данных следующим образом:

table_photos
- photo_id
- photo_filename
- photo_date
- photo_user_id
- vote_id
- warn_id
- type
- detail_id

table_houses
- id
- name
- style

table_trees
- id
- name
- species

В этом случае вы можете определить свой объект фотографии в поле type, например, 1 = Дерево, 2 = Дом и т. Д. У вас все еще будет возможность иметь много фотографий для одного объекта без дублирования данных, но вам не придется создавать таблицы table_rel_xxx с повторяющейся схемой столбцов. Я предпочитаю избегать этого, когда это возможно.

В этом случае вы сможете создавать запросы, такие как:

SELECT 
    table_trees.name
FROM
    table_photos
INNER JOIN
    table_trees ON 
    (table_trees.id = table_photos.detail_id AND table_photos.type = 1);

Или просто запросить все фотографии без «позднего связывания» с определенным типом:

SELECT 
    photo_filename
FROM
    table_photos;

Вам может быть интересно ознакомиться со следующими статьями, связанными с этой моделью базы данных:

• Переполнение стека - полиморфизм в таблицах базы данных SQL?
• Data, Design и SQL Server - непересекающиеся подтипы в SQL

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

Одним из недостатков этого метода является то, что он делает ограничения внешнего ключа довольно сложными для определения. Вам понадобится ограничение внешнего ключа, чтобы гарантировать, что если table_photos делает ссылку на строку в table_trees, эта строка действительно существует. Решение этой проблемы с внешними ключами приведено на очень хорошем примере в следующей статье EMC:

• Распределенные ключи и непересекающиеся подтипы