Что лучше? Несколько таблиц с одинаковыми сущностями против нескольких таблиц отношений, имеющих больше записей

Question

Что лучше? Несколько таблиц с одинаковыми сущностями против нескольких таблиц отношений, имеющих больше записей

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

Таблица 1: Проблемы Muncipal:
Я БЫ,
Идентификатор пользователя,
Заглавие,
Место нахождения,
Описание,
URL изображения,

Таблица 2: Проблемы с притяжением:
Я БЫ ,
Идентификатор пользователя,
Заглавие,
Место нахождения,
Описание,
URL изображения

Таблицы 3 такие же, как выше

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

с одной стороны, будет слишком много таблиц с одинаковыми столбцами.
с другой стороны, там будет несколько таблиц с большим количеством строк.

Что будет лучше для производительности больше строк или больше таблиц.

Я использую Mysql.

0

mysql php rdbms relational

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Во-первых, если вы не ожидаете, что миллионы записей будут заботиться не столько о производительности, сколько о структуре ваших данных и о том, как легко будет получить к ним доступ. Буквально запишите список данных, которые вы планируете извлечь в вашем приложении, например. «найти все проблемы сегодня», «найти все нерешенные проблемы старше 6 месяцев», а затем попытаться построить реальные запросы SQL на ожидаемой структуре. Если они идут усердно, попробуйте изменить структуру.

Чтобы ответить на ваш вопрос: это зависит. Текущая структура имеет следующие преимущества:

Легко задавать вопросы определенного типа
Создать приложение PHP легко — просто создайте одну шаблонную форму (или модель), а затем скопируйте ее с небольшими изменениями для других таблиц.
В случае проблем с производительностью может быть проще создать кластер, просто поместив каждую таблицу на отдельный сервер БД.

и следующие недостатки:

Это негибко. Добавление нового поля, которое вы забыли добавить в начале, будет болезненным, поскольку вам придется изменить 3 (или более) таблицы, а затем столько же частей в вашем приложении.
Добавление новых типов проблем будет болезненным и потребует создания новой таблицы.
Создание SQL-ов для получения данных типа «все нерешенные проблемы (независимо от типа)» потребует сложных UNION-s. Более того это UNIONS потребует создания виртуального поля с типом проблемы, иначе вы не сможете определить, из какой таблицы пришел определенный идентификатор.

Классический подход БД рекомендует использовать одну таблицу для общих полей и создавать производные таблицы для полей, которые отличаются. Так:

issues таблица должна иметь все общие поля и идентифицируется по PK issue_id
municipal_issues использует внешний ключ для issues.issue_id и имеет только определенные поля
harassment_issues использует внешний ключ для issues.issue_id и имеет только определенные поля
так же issues стол имеет issue_type поле, которое принимает значения «домогательство», «муниципальный» и т. д. и помогает найти таблицу, в которой хранятся дополнительные данные.

Эта картина называетсяНаследование таблицы классов«и вы можете проверить Антипаттерны SQL презентация для получения дополнительной информации и других подходов. Это решает проблему гибкости и по-прежнему позволяет воссоздавать каждую из исходных таблиц только с одним простым JOIN, который выполняется довольно быстро.

Также в качестве примечания вы можете посмотреть на схему БД для трекеров ошибок, таких как Богомол так как это выглядит как один и тот же домен.

1