Я реструктурирую объявления MySQL db, где различные основные разделы разделены на отдельные таблицы. Например, у предметов продажи есть своя таблица с уникальными идентификаторами, у рабочих мест есть своя таблица с уникальными идентификаторами, у персонажей есть своя таблица.
Все эти разделы имеют несколько общих характеристик:
-id
-title
-Боди
статус-списка
-poster
-reply email
-posting date
Но у каждого из них есть отдельная информация:
-each имеют разные наборы и деревья категорий на выбор (которые влияют на структуру, необходимую для их хранения)
-jobs нужно хранить вещи, такие как зарплата, дата начала и т.д.
-специальные предметы должны хранить вещи, такие как цены, obo и т.д.
Следовательно, лучше ли реорганизовать db, пока я могу, в универсальную таблицу, чтобы хранить ВСЕ общую информацию о листинге вне зависимости от раздела, а затем запросить настраиваемое хранилище данных для небольших таблиц или лучше оставить текущей структуры и оставить разделы разделенными?
Не используйте отдельную таблицу. Перейдите к реляционным.
То, что я рекомендовал бы настроить, - это так называемая полиморфная связь между вашей "основной" таблицей (той, которая имеет общие характеристики), и тремя таблицами, содержащими конкретную информацию. Структура будет выглядеть примерно так:
Основная таблица
Таблица категорий
В поле category_name должно быть указано имя таблицы конкретной категории, например. 'job_category', а category_id должен указывать на идентификатор в таблице категорий. Пример будет выглядеть следующим образом:
# MAIN TABLE
id | title | ... | category_name | category_id
-------------------------------------------------------
123 | Some title | ... | job_category | 345
321 | Another title | ... | sale_category | 543
# SPECIFIC TABLE (job_category)
id | ...
---------
345 | ...
# SPECIFIC TABLE (sale_category)
id | ...
---------
543 | ...
Теперь, всякий раз, когда вы запрашиваете основную таблицу, вы сразу же узнаете, в какой таблице будут извлекаться дополнительные данные, и вы будете знать идентификатор в этой таблице. Единственным недостатком этого подхода является то, что вам нужно выполнить два отдельных запроса для извлечения информации для одного элемента. Однако, вероятно, это возможно сделать в транзакции.
Для получения данных другим способом (например, вы ищете категорию jobs_category для чего-то), с другой стороны, вы можете получить связанные данные из основной таблицы с помощью JOIN. Не забудьте не только присоединиться к main.category_id = jobs_category.id, но также использовать столбец category_name в качестве условия соединения. В противном случае вы можете получить данные, относящиеся к одной из других категорий.
Для обеспечения оптимальной производительности вы можете индексировать столбцы category_name и category_id. Это в основном ускорит любые запросы, которые объединяют две таблицы, как описано в предыдущем абзаце.
Надеюсь, это поможет!
Похоже, что это все отдельные объекты, которые не имеют ничего общего друг с другом (ecxept для обмена некоторыми определениями столбцов), правильно?
Вы когда-нибудь хотели бы сделать SELECT как
SELECT *
FROM main_entity
WHERE entity_type IN ('SALE_ITEM', 'JOB', 'PERSONAL')?
В противном случае я не думаю, что объединил бы их в одну таблицу.