Лучше как минимум отгородить таблицу логин и пароль. В целях безопасности.
А по скорости. То лучше разделите их на логические части.

Т.е. к логину и паролю обращаетесь редко - ну и пусть будет для них своя таблица.

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

Zerstoren
По скорости мне кажется потеряется, тк допустим есть модуль траффик, в нем IP-шники, которые привязаны к пользователю так запрос получается допустим такой:

SELECT id,firstname,lastname FROM users WHERE ip='$some_ip'

А если я разделю будет примерно так..

SELECT u.id,u.firstname,u.lastname FROM users u INNER JOIN users_ips up ON u.id=up.user_id WHERE up.ip='$some_ip'

Всё зависит от того какого рода дополнительная инфа о пользователе. Если она напрямую является сущностью пользователя, то лучше всё оставлять в одной таблице.
Скажу иначе, если связь между пользователем и инфой пользователя в обоих направлениях есть связь"один к одном", то это одна сущность пользователь, а значит должна храниться в одной таблице. При отображении списка пользователей позволит избежать явно лишнего JOINа.

linker
Ясно, спасибо, а логин, пасс лучше отделить всеж?

Renden
Не имеет никакого смысла, но при обозначенном мною выше условии.

вообще конечно любопытная дилемма. когда я учился, нам говорили, что надо обязательно все разделять по максимуму. и не создавать такие столбцы, значения в которых могут быть скажем вычислены.
однако когда я писал галерею, мне надо было выводить там количество комментариев к каждой фотке (вообщем на странице куча фоток и под каждой написано Комментариев-100 например. Мы кликаем на эту ссылку и видим эти комментарии). Мне сказали, что нерационально для каждой фотки заниматься подсчетами или даже использовать group by в таблице комментариев по ид фотки, поэтому я количество комментариев сделал прямо в таблице фоток и все выуживается одним селектом. Просто при добавлении комментария или удалении получается +1/-1 для этой фотки соответственно (тот же триггер).
Так что тут тоже надо смотреть как лучше/быстрее.

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