Привет,  у меня возник вопрос по производительности MySQL сервера:
есть структура, содержащая много полей. Поля логически разбиты на некоторые группы, в частности адрес_типа1 (7 полей), адрес_типа2(4 поля).
Как лучше проектировать систему:
1) все поля в одной таблице, делать выборку по нужным полям.
2) Создать дополнительные таблицы, делать выборку JOIN`ом.

И вообще, как влияет количество полей в таблице на производительность сервера?..
Заранее спасибо.

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

Надо смотреть по задаче

02077461, 
Читай насчет нормальных форм. Т.е. любую книжку по СУБД, в которой есть слова "нормальная форма", "нормализация"... Иначе дров наломаешь.

Спасибо за совет. Буду просвещаться.

Решил продолжить тему, а не создавать новую. Считаю тему нераскрытой! Люди, очень интересует сабж, очень очень важно. Сейчас проектируется бд, и очень важно решить, будут ли храниться данные, не очень относящиеся друг к другу, в одной таблице но с 100 полями, либо в 2-х логически разделенных но с полями по 50 в каждой? Понятно что второй вариант намного лучше в плане нормализации, однако он потребует очень сильной корректировки движка что очень геморно. 

Вопрос: как сильно влияет, и влияет ли вообще количество полей в таблице на производительность, даже если не использовать SELECT *, а только SELECT needed_field1, needed_field2, needed_field3

Надеюсь, тебе не нужна прописная истина, что "если выбросить из таблицы все поля, не использованные в запросе, будет получена максимальная скорость обработки"?
Так вот - твой вопрос без кучи дополнительных данных лишён смысла.
На ответ будет влиять как соотношение количества запросов к одной/двум таблицам, так и количество в среднем выбираемых записей, процент кэшированных данных, повторяемость запросов и кэширование результатов, количество клиентов и погода на Марсе ... в общем, ТОЛЬКО опытным путём можно узнать, каково влияние в каждом отдельном конкретном случае. 
Но и оно может одним махом поменяться от незначительных на первый взгляд изменений.
В общем случае - разделение 1:1 следует однозначно рекомендовать, когда существуют устойчивые группы наборов полей выборки, позволяющие не затрагивать одну или несколько частей совокупного набора данных.

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

Ой, да ладно... в чём?
Выполняем разделение данных на несколько таблиц. Пишем вьювы, объединяющие данные и представляющие их так, как будто структура не поменялась (а вьюв 1:1 - однозначно обновляемый). После чего спокойно, не останавливаясь, пишем новый код сразу на новую структуру, а существующий плавно переделываем со старой структуры на новую. Когда всё переделано - просто прибиваем вьюхи.

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

Добавлено через 44 секунды
вопрос как бэ закрыт, но ценные советы и ответы будут приветствоваться.

зависит от цели. Если количество данных планируется хранить большое и пользователей много и всем информация нужна сразу и ждать просто не как нельзя  -  тогда нормализация. Здесь кратко:
http://www.wwwmaster.ru/article.php?nart=21  . А если это не проблема - то какая разница. Но делать нормализацию - это красиво