Здравствуйте, сделал вот такой SQL запрос Код (Text): SELECT a.id as 'a.id', a.title as 'a.title', a.introtext, a.lang, b.con_id, b.cat_id, c.id as 'c.id', c.title as 'c.title', l.id as 'l.id', l.title as 'language' FROM category c INNER JOIN category_list b ON b.cat_id = c.id INNER JOIN content a ON a.id = b.con_id INNER JOIN language l ON a.lang = l.id WHERE c.id = :catid ORDER BY a.id LIMIT 0,20 Подскажите, не слишком он уж жирный?) И нужно ли его оптимизировать? Заранее спасибо! ПС Код (Text): category id - title category_list con_id - cat_id content ..... lang language id - title
и тогда будет понятно, надо ли оптимизировать? Ну допустим разберём. Как тогда понять, надо ли оптимизировать?
Действительно, ТС чем отличать "жирноту" запроса? Тут в проектике некоторые последние запросы по 100 Кб. весом примерно (голые, еще без параметров), неужели пора?
Хмм, вот смотрите Раньше запрос был такой: Без таблицы language. Запрос выполнялся в среднем за 0.0006 сек. (варьируясь 0.0005 - 0.0008 ) (локалка) При выборке 20 материалов Код (Text): SELECT a.id AS 'a.id', a.title, b.con_id, b.cat_id, c.id AS 'c.id', c.title AS 'c.title' FROM category c INNER JOIN category_list b ON b.cat_id = c.id INNER JOIN content a ON a.id = b.con_id WHERE c.id = :catid LIMIT 0 , 20 Теперь мой новый запрос был выполнен за 0.0089 сек. в среднем (варьируясь 0.0057 - 0.06xx) с тем же количеством материалов Код (Text): SELECT a.id AS 'a.id', a.title AS 'a.title', a.introtext, a.lang, b.con_id, b.cat_id, c.id AS 'c.id', c.title AS 'c.title', l.id AS 'l.id', l.title AS 'language' FROM category c INNER JOIN category_list b ON b.cat_id = c.id INNER JOIN content a ON a.id = b.con_id INNER JOIN language l ON a.lang = l.id WHERE c.id = :catid ORDER BY a.id LIMIT 0 , 20 Здесь наглядно видно, что второй запрос в n-раз медленнее. Вот я и думаю, как сделать чтобы он стал легче
Несомненно вы правы, это очень мало. Но тот факт что, из 0.0006 стало 0.008 как-то печалит. Внутри меня умирает перфекционист
разбивай на несколько, делай отдельные запросы, кеширование спасёт. Ты кстати попробуй писать SELECT SQL_NO_CACHE и выбирай двадцать не с нуля, а с пятой тыщи записей. тады будет веселее.
насколько я понял, задача иметь несколько вариантов написания заголовка категории. причем язык этого заголовка задается в поле контента. возникает сомнение: вариант а) если заголовок это часть контента, не проще ли было поместить текст заголовка в таблицу контент? тогда переводы не нужны. вариант б) если заголовок относится к структурным элементам, то не логичнее ли было привязаться к локали пользователя и ВЕСЬ интерфейс выводить этим языком? тогда переводы не будут зависеть от контента
Возможно так станет яснее, что у меня происходит Есть 4 таблицы На сайте организованы мульти категории, т.е. у n-материала может быть n-категорий, поэтому я использовал многие ко многим. В поле lang находиться id отсюда language.id content id - ... - lang category id - ... - parent-id Здесь соответственно хранятся content.id и category.id category_list con_id - cat_id В данной таблице хранятся, пример: (русская народная сказка, украинская и т.д.) language id - title Добавлено спустя 7 минут 12 секунд: Хотя я подумал, наверное логичнее будет сделать content.lang varchar и туда записывать en, ru, ua.. А уже средствами php выводить нужную информацию..
Про N категорий понял, всё остальное не понял ))) Сомнения остались прежние. Пусть твои категории это теги (таксономия). Нафиг их язык связывать с языком текста? И вообще надо ли им иметь язык?! Добавлено спустя 6 минут 40 секунд: p.s. Кстати чето не увидел я в твоем запросе как ты управляешся с many-to-many. Помоему никак Контент полюбому надо добывать отдельно от его тегов, иначе запрос будет получать N копий текста, а кому это надо? Добавлено спустя 2 минуты 21 секунду: Короче не жилец однозначно. Разберись сначала с тегами как таковыми, а языки и тем более "оптимизацию" как-нибудь потом продумаешь, если вообще до этого дойдет…