Добрый день!

Есть таблица users.

Три столбца:
name (имя), age (возраст), city (город)

Таблица маленькая, но проблема вот в чём, как лучше организовать столбцы,
помимо этих трёх добавятся ещё порядка 50 (а потом ещё 200), в ширину таблица получится огромная,
стоит ли её разбивать на несколько? Если да, то есть ли какой-либо стандарт для решения этой задачи?

Стандарт?)
Проектирование здесь зависит от данных, которые будут добавляться... Может быть потребуются связи с другими таблицами.
Но разбивать как-то указанные данные, я не вижу смысла, и если все остальные имеют такой же характер, то почему бы просто не увиличивать степень отношения..
Но если появится другой объект, то просто следует создать для него таблицу и поразмыслить над её связью с уже существующим.

что и как ты хочешь добалять, а главное зачем???

базы данных нужны для "правильного" хранения данных... а ты, как я понял, хочешь все данные в одну таблицу....

Есть, называется - нормальные формы.

Связи с другими таблицами конечно же потребуются, хотим разбить таблицу следующим образом (на 2 шт.):



Таким образом можно будет хоть 1000000 дополнительных полей для каждого пользователя сделать,
правильный ли этот подход? Связь будет users.name = parameters.name

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



Спасибо за подсказку, почитаем.

Неправильный. Связь лучше с точки зрения производительности базы данных и неизбыточности данных осуществлять по целочисленному уникальному ключу.

Что же касается идеи использовать таблицу parameters:
опять же либо поле columnname должно быть типа enum, но тогда нужно будет алтерить таблицу при каждом добавлении нового поля, либо columnname - должен быть идентификатором (columnname_id), указывающим на уникальный ключ в словарике-таблице из двух полей columnname_id | columnname.



Увы, не всё так просто. Возможности MySQL по работе с большими таблицами ограничены.
Из своего опыта: на мощнейших серверах работа с таблицами > 100 млн записей становится сложной. Из таблицы в четверть миллиона зписей для сервиса в реальном времени выбрать что-либо даже по ключу уже невозможно, такие таблицы годятся только для фоновых процессов. Таблицу больше 1 млрд строк можно сгенерить, но с ней работать уже скучно даже в фоне.

name int unsigned auto_increment primary key



Подход к решению задачи по Вашим словам - правильным.
Везде будет использоваться ключевое слово id (nameid, ...) (primary key).

Тип enum автоматически отпадает, использовать его неудобно,
планируем использовать несколько типов данных для parameters (varchar, timestamp, int).
Т.е. есть анкета, в ней немеренно вопросов, некоторые ответы подпадают под тип VARCHAR,
другие под SMALLINT(3), другие под TIMESTAMP(14), хранить их все в VARCHAR - не целесообразно.



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

muzer, 

Если думаешь, что это только у MySQL такие проблемы, то зря. Прошвырнись по соседним серверам - все примерно так же.
СтудентИзРоссии, 

DelphiKingdon или местный FAQ - Тенцер "Естественные ключи против искусственных ключей". И вообще "удобно-неудобно" - не те термины. Куче обормотов удобно фамилию, имя, отчество в одно поле забивать, например. А по уму за такое сразу увольнять надо без выходного пособия.

Добавлено @ 12:10 
Пардон, опечатка. DelphiKingdoM (а не n)

Может быть Вы и правы, но именно по нашей теме можете что-нибудь посоветовать? 

можем. три таблицы. отдельно - люди:
men
idman int unsigned auto_increment
name varchar(80)
отдельно - параметры
params
idparam int unsigned auto_increment
name varchar(80)
отдельно - значения параметров для разных людей:
men_params
idman unsigned int
idparam unsigned int
value varchar(60)
primary key(idman, idparam)
тогда будь хоть 2000 параметров - просто в таблице params будет 200 записей. но не полей.
это, кстати, и есть нормальная форма(одна из), ссылку на инфо о которых давал muzer ещё ночью 

Благодарим за пример!

Про нормальные записи уже начали читать.

нормальные формы 
однако, НФ - это не панацея. все сильно зависит от задачи. порою стОит хранить ФИО в одном поле и делать де-нормализованные таблицы.