Mysql UNION | UNION ALL - скорость работы

[PHProgress]

У меня есть одна таблица в которой хранится все содержимое - контент.
Контент разибвается по типу на основе одного поля typecotent (image, document, html, text и т.д.)
И в зависимости от typecotent применяется различный php-код...
Т.им образом извлекая картинки - к примеру, есть лишние не заполненные поля, которые к примеру придут от document - вес файла и т.д.

Таким образом запрос на выборку данных проходит следующим образом:
SELECT * FROM content WHERE page = 1;

Все бы ничего - но появилась необхоидмость попробовать создавать на каждый тип контента - одлельную таблицу. Решение вопроса нашел в ипользовании UNION ALL

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

И приходится делать что-то вроде

SELECT id, page, title, sizedocum, desription, null, null FROM table_documents WHERE page = 1;
UNION
SELECT id, page, title, null, null, image_width, image_height FROM table_images WHERE page = 1;

Тему создал - что бы спросить - стоит ли игра подобных свеч?
И как это скажется на скорости работы? - т.к. мне в каждый запрос придется вставлять кучу null там, где нет колонок в таблицах...

 

[SiZE]

Надо исходить из поставленной задачи. Для чего тебе этот запрос? Тебе надо вывести постранично эти данные в одной таблице?

 

[PHProgress]

Хочу сделать разделение типов-содержимого сайта по таблицам - т.к. мне не очень удобно использовать одну таблицу...
Каждой таблице я задаю набор полей - что бы пользователь мог их отредактировать...

Сейчас у меня порядка 25-типов содержимого.
Целесообразно ли их разносить по раздным таблицам?

А на сайте использовать не SELECT а SELECT к нескольким таблицам.
Кроме того, мне нужно что бы этот UNION мог выводить и по страницно, и сортировать список записей.

Или в данной случае UNION - это излишне?

 

[WMix]

PHProgress
много разговоров, уже мог написать бы для базы с 100 таблиц... будет медленно создай позже cache ...

 

[SiZE]

Ну можно хранить общие данные в одной таблице (удобно сортировать, быстро выводить), а атрибуты отдельно загружать. Например, первая таблица у тебя: id, page, title, наверное путь к файлу еще хранишь, а вторая уже id, link_to_main_table, attribute_name, attribute_value. Для оптимизация и ускорения работы простор получишь, например вместо attribute_name можно хранить внешний ключ на таблицу-справочник атрибутов.

 

[fixmax]

Делай как говорит SiZE. Сэкономишь много нервов.

 

[PHProgress]

В общем отказался я от этой идеи, пока...