@WebSpider: и о какой разнице в производительности идет речь? В среднем, статья будет состоят из 10 секций и по 5 наследников к секции. Я планирую, записывать результаты выборки в memcached, до следующего UPDATE, которые будут крайне в исключительных случаях.
@WebSpider: то-есть, сливать два результата в 1 массив, сортировать по position и тогда снова запускать цикл? А если к figure, paragraph еще добавить lists, polls?
@WebSpider: и выборка наследников секции (параграфы, фигуры, списки):
SELECT
`paragraph`,
`resource`,
`figcaption`
FROM
((SELECT `position`
FROM `paragraph-section-article`
WHERE `section` = $id)
UNION
(SELECT `position`
FROM `figure-section-article`
WHERE `section` = $id)
) `paragraph+figure`
LEFT JOIN `paragraph-section-article` USING (`position`)
LEFT JOIN `figure-section-article` USING (`position`)
WHERE COALESCE(`paragraph-section-article`.`section`, `figure-section-article`.`section`) = $id
ORDER BY `position`;
@WebSpider: имеем 3 запроса. Выборка статей SELECT
`id`,
`uri`,
UNIX_TIMESTAMP(`date-modified`) as `date-modified`,
`title`
FROM `article`
ORDER BY `date-modified` DESC
LIMIT $start_limit, $end_limit;
@WebSpider: и снова-таки, мы сейчас работаем с таблицами paragraph... и figure... именно их нужно объединять. Для таблицы секций, пара article+position тоже всегда уникальна, а выборка производится всегда для 1 article.
@WebSpider: section+position всегда уникальный. Выборка происходит всегда только для 1 section, соответственно, position всегда уникальны и их можно расположить по порядку.
@WebSpider: да, конечно. arturkohut.com/temp/arturkohutcom.sql . В принципе, оба запроса дают нужный результат. Вариант без JOIN вроде бы выполняет меньше действий и думаю, будет работать быстрее. Но снова-таки, я дилетант.
@WebSpider: нет, position всегда уникальный, но всегда присутствует, как и присутствует `section`. Просто нужно выбрать из 2 таблиц с похожим содержанием контент, и группировать его по `position`, где `section` у обоих определенное число.
@WebSpider: если указывать section в подзапросах, where в итоге все-равно не учитывает. Скриншот в ответе ниже. Работает, только если указать WHERE во всех запросах.
@WebSpider: если написать where в подзапросе, после JOIN, WHERE уже не действителен. Например, WHERE section = 1, а в итоге, мне выводит все секции.
> почему?
Если честно, я вообще профан в СУБД. Но планирую выучить. Мне кажется, что 2 запроса, 2 JOIN еще и по функции прогонять это не слишком продуктивно. Для вас это нормальный код?
Можно ведь обойтись и без JOIN, просто UNION LEFT JOIN + UNION RIGHT JOIN и нужные поля склеивать по COALESCE. Этот вариант продуктивнее?