Эффективные Объявления Mysql Структура

Question

Эффективные Объявления Mysql Структура

0

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

Все эти разделы имеют несколько общих характеристик:

-id
-title
-Боди
статус-списка
-poster
-reply email
-posting date

Но у каждого из них есть отдельная информация:

-each имеют разные наборы и деревья категорий на выбор (которые влияют на структуру, необходимую для их хранения)
-jobs нужно хранить вещи, такие как зарплата, дата начала и т.д.
-специальные предметы должны хранить вещи, такие как цены, obo и т.д.

Следовательно, лучше ли реорганизовать db, пока я могу, в универсальную таблицу, чтобы хранить ВСЕ общую информацию о листинге вне зависимости от раздела, а затем запросить настраиваемое хранилище данных для небольших таблиц или лучше оставить текущей структуры и оставить разделы разделенными?

johnnietheblack 18 дек. 2009, в 07:58

Источник

Теги:

mysql

architecture

2 ответа

2

Похоже, что это все отдельные объекты, которые не имеют ничего общего друг с другом (ecxept для обмена некоторыми определениями столбцов), правильно?

Вы когда-нибудь хотели бы сделать SELECT как

SELECT *
FROM main_entity
WHERE entity_type IN ('SALE_ITEM', 'JOB', 'PERSONAL')?

В противном случае я не думаю, что объединил бы их в одну таблицу.

Peter Lang 18 дек. 2009, в 06:10

Ещё вопросы

vonconrad · Accepted Answer · 2009-12-18T09-37-00.000Z

Не используйте отдельную таблицу. Перейдите к реляционным.

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

Основная таблица

ID
название
...
category_name (VARCHAR или CHAR)
category_id (INTEGER)

Таблица категорий

ID
(конкретные столбцы)

В поле 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. Это в основном ускорит любые запросы, которые объединяют две таблицы, как описано в предыдущем абзаце.

Надеюсь, это поможет!