Если у меня в таблице users, где хранятся данные юзеров аж 25 полей информации. 
Таблица – как вы сами понимаете очень востребована, и обращаться к ней будут часто. Да и разрастись она должна быстро.

Как это может угрожать производительности скрипта? 

Для обращения я использую PDO.

25 это небольшое количество полей. Такое количество полей практически никак не влияет на скорострельность

Рыжий, главное грамотно подбери типы данных и все будет хорошо.

Хорошо, постараюсь.

Рыжий, искренне надеюсь, что со временем не окажется, что в половину из этих полей придется пихать данные массивами, а вторая половина может быть NULL  
Естественно, всё зависит от того, что хранится в тех 25 полях и как ты эти данные собираешься обрабатывать   

вообще-то меня это тоже волнует... У меня сейчас есть таблица в которой порядка 40 полей, в половине из них небольшие массивы.

Как по другому сделать не представляю. Эти поля - описание объекта.

Единственный вариант - разделить таблицы, но тогда придётся делать сложные запросы по 3-м - 4-м таблицам.


Есть ли где в мануале какие либо ограничения по этому вопросу?

Gold Dragon, 
Лучше нормализовать. Будет меньше и универсальнее.

Gold Dragon, ты бы задачей поделился...
а так, в общем виде, нормализация с последующими inner join'ами по ключам мне видится более быстрым делом, нежели работа с не-атомарными полями средствами СУБД..
да и 3-4 join'a - это, в принципе, не предел. насколько я помню, ограничения в СУБД при конфигурировании накладываются на количество строк, выбираемых join'ами на промежуточных этапах отбора, а не на уровень вложенности...

Вот смотрите...

есть объект
- id
- назвние
- адрес .....
- что-то ещё такое

а потом
- стены Array(
          - материал, 
          - цвет, 
          - высота, 
          - ширина
          -.....)
- проводка Array(
          - материал, 
          - сечение, 
          - длина, 
          - оплётка
          - ......)
- режим работы Array(
         - понедельник Array(
              - начало
              - конец
              - перерыв
              - выходной
              - ....)
           - вторник Array(.....)

и так далее

я сначала делал все характеристики в разных таблицах, но с запросами целая беда. А теперь всё в одной таблице. Одна выборка и все данные "в кармане".
Проблем с торможением, зависанием и т.п. не заметил, вот и оставил одну таблицу. Просто кроме этой таблицы есть ещё целая куча.

Gold Dragon, а если, например, у объекта внешние стены из бетона, а внутренние из ценных пород древесины, проводка разных типов и режим работы зависит от четности недели и т.д. Как будешь хранить такую инфу?


да никаких там бед не должно быть: пара джойнов, пара условий, группировочка - готово.

ЗЫ. SQL без JOIN, как пиво без газа   

лучше так: как безалкогольное пиво, как надувная женщина, как искусственная елка... 

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

т.е., судя по всему, надо нормализовать.

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

что касается  всё предусмотрено   есть специальное поле для пояснений и комментариев "PS".

Если мне рассовывать всё по разным таблицам, то таблиц будет порядка 25-30.  И ещё плюс других штук 15... Нафига такая база... запутаешься  А так всё лежит в одном месте... Если это дозваляется в MySQL, то почему бы и нет..

у меня в последнем проекте было 122 таблицы. и я не хвастаюсь.просто констатирую факт. и не запутался.
дело не в количестве. дело, в первую очередь, в систематизированном подходе к наименованию. если у тебя одно и то же поле называется по-разному(например, главный ключ в одной таблице - просто id, а внешний ключ в другой таблице  - уже "idsomething"), то работать сложно. если у тебя куча таблиц относятся к одному и тому же - лучше дать им одинаковые префиксы... 
У меня вот такой подход:
1. одинаковые поля называются одинаково в разных таблицах(idtopic у меня и в таблице topics, и в таблице topics_names и в таблице topics_regions означает одно и то же, хранит в одинаковом виде, и называется одинаково - не запутаешься)
2. "групповые" таблицы(имеющие отношение не ко всему проекту, а к отдельной части) имеют одинаковый префикс("sort_heads", "sort_heads_names", "sort_titles", "sort_functions") - набирать дольше(если нет автозавершения в оболочке-администраторе  ), но названия выглядят однозначно и функционал даже части запроса очевиден.
3. таблицы, реализующие отношения "многие-ко-многим" называются так, чтоб включать в себя название обоих типов объектов("rows_names","rows_regions","rows_directions") - пожалуй, тут всё же нужен элемент привыкания, потому как связь между странами и полосами может называться как "rows_regions", так и "regions_rows", но если на первое место вставлять более "специфический" объект(не могу понятней объяснить  )
не обязательно - при такой; при любой системе наименований руки будут набирать  названия полей и таблиц практически самостоятельно, да и читать запросы будет намного проще  И уж тем более, не будешь сторониться join'ов 

да это всё понятно.. просто именно в этом проекте для меня так делать удобнее.
Да и вопрос малость другой... Выдержит ли MySQL? Если я правильно понял, специально этим вопросом никто не занимался и глюков замечено не было. Но, если честно, хотелось бы узнать предел.. в доках ничего не нашёл (может просто плохо читал  )

Gold Dragon, 
Так попробуй. Берём ab и вперёд.