armancho7777777
Спор зашел в тупик.

Ну если 1-2 тыс запрос в секунду то да может справиться, но а если 10-20 тыс, то вот такие вот запросы и нагрузят бд, и опять же речь идет о описании категорий...

Что ???

А можно объяснить смысл использования в данном случае хранимых процедур?

armancho7777777
Не не то, я имею ввиду каким образом хранимые процедуры тут этот процесс сгладят.
Можно на пальцах...

vanicon, Вы может у гугла спросите?
Терпеть не могу объяснять людям что-то,
которые не знают и спорят, спорят...
(Добавление)
Спорите, утверждаете, но даже не знаете что mysql запросы кеширует.
Об остальном я уже и не заикаюсь.

armancho7777777
Конечно могу, но чуть позже...

А вот в этом месте можно по подробнее, где вы считаете что я не то пишу, мне же тоже интересно где можно сделать лучше и т.п, насчет хранимых процедур и масштабируемости пишут что две несовместимые вещи, сам не пробовал, но думаю что верно, как вы считаете?
Также хочется прочитать ответ на вопрос, конкретнее к теме, вы и правда считаете что вынос подобного поля в отдельную таблицу это правильно?

Начиная с версии 5.6 InnoDB поддерживает полнотекстовый поиск. Поэтому, если я верно понял суть спора - то он не имеет смысла.

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

Не знал.
Радует ))

armancho7777777
Ну теперь наверно с версии 5.6 смысла выносить в отдельную таблицу уже нет да?

Ну конечно нет ))
Да, это было неприятная особенность этого движка.
Единственное что, не все хостеры обновились.

Отвечая на вопрос про поиск - я бы использовал Sphinx. Просто потому, что он для этого предназначен. Он имеет возможность искать независимо от окончания (в том числе множественные словоформы, окончания которых нестандартны) и снимает нагрузку с СУБД. Если быть более корректным, то он не снимает эту нагрузку совсем, но позволяет выделить удобное время для индексирования, тем самым снизив нагрузку в критичные часы.

Насчёт варианта вынесения поля - не очень понял, где порождается "тяжёлый запрос" (LEFT JOIN по PRIMARY KEY тяжёлый?) Не очень понятно и то, что заставляет считать хранимые процедуры немасштабируемым решением. Можно, конечно, написать код так, что он будет работать только на небольших таблицах, однако же это нужно постараться (или - напротив - совсем не стараться и написать непрофессионально). Дело другое - то, что я не знаю, зачем использовать хранимые процедуры для поиска. Здесь уже явно напрашивается сторонний поисковый движок - например, тот же Sphinx. Как правило, для Sphinx требуется написание VIEW, но не процедуры.

Иногда, кстати, даже рекомендуется вертикальное партиционирование таблиц (то есть вынесение части таблицы в другую по связи 1:1) - например, если вспомнить, что в MySQL предельно допустимый размер строки вместе со всеми указателями и разделителями есть 65536 байт. Или если в таблице есть объёмные поля, которые меняются редко, тогда как другие - запрашиваются часто - примеров можно придумать много.

armancho7777777
Прошу прощение если чем то задел, в любом случае спор закончен, просто смотрел как в других cms, да и сам не видел смысла почему вы утверждали что нужно выносить в другую таблицу какое-то поле, поэтому настаивал на своем...

То есть я так понял, что все валить в большие таблицы?
Категории, статьи, комменты, пользователи...
Так?
А как же нормализация?