mysql база пользователей и профайлы

Всё зависит от задачи.

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

Бывает также такая архитектура системы, когда сам профиль можно поделить на несколько независимых блоков. Для примера, онлайн-игра: таблицы - 1) логин-пароль; 2) общая информация о игроке, здоровье и т. п.; 3) крупная таблица id'ов одежды и вооружения для каждой отдельной части тела.

Кроме того, информация в таблице логина-пароля меняется редко и по этой причине таблица в меньшей степени подвержена фрагментации. Но вообще вопрос тонкий, в тех же высоконагруженных проектах дополнительно ещё используется memcached.

Инфа к размышлению: такие крупные форумы, рассчитанные на высокие нагрузки как VBulletin и IPB хранят логины и профиль в одной таблице.

>такие крупные форумы, рассчитанные на высокие нагрузки как VBulletin и IPB
Унылое устаревшее говно с никакущей архитектурой. Ни на какую высокую нагрузку они не расчитаны.
Остальное, в целом, верно. Выносить стоит тогда, когда полей много, а используются редко.
Хотя я бы такие вещи хранил бы вообще в какой-нибудь MongoDB.

LDAP! LDAP же, ну! Он для того и придумывался. А все ваши «носкл база для хранения объектов с произвольным количеством свойств» как раз и придумали те, кто не осилил ЛДАП

так-то!

Лдап тоже хорошо, но больно энтерпрайзненько.

> Унылое устаревшее говно с никакущей архитектурой. Ни на какую высокую нагрузку они не расчитаны.

Новые, переписанные с нуля версии - VBulletin 4 и IPB 3, хоть и говно, но если судить по заявленным возможностям работы с memcached, отключению части функциональности в период перегрузки форума от наплыва посетителей и (точно не скажу, но что-то помнится) репликации БД на несколько серверов, рассчитывались на масштабирование.

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

JOIN не такой и страшно затратный, если там одна таблица.

Ну а если ты не будешь искать по этим данным, то можно вообще хранить весь профиль в сериализованном виде прям внутри users. Например в xml, благо многие БД умеют xpath, если уж припрёт поискать.

http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

спасибо !

Создал небольшие таблицы по 20 к записей. Сделал пару простых тестов для себя. на фундаментальное подтверждение не претендуют :)

1) Проверил аутентификацию, выборка данных в смешанной таблице таки больше занимает времени. При раздельных таблицах, когда users содержит несколько полей, выборки идут быстрей.

2) Left join работает, что интересно не медленней, даже быстрей. Например поиск по некоторым данным из профайла с выборкой данных пользователя из таблицы users посредством left join.

3) И я так понял любая выборка даже 1го поля в перегруженной таблице будет занимать больше времени чем 1го поля в разгруженной таблице (разнесем поля для users&profile отдельно)

4) Организация данных будет логичней.

Вообщем, очень похоже на то, что стоит разделить данные авторизации и профайла ( в дальнейшем по нем будут поиски ) .

ну это как бы не для раздельных таблиц, а оптимизаци для одной таблицы, возьму на заметку :)

Ну не сказал бы, что с «никакущей архитектурой» vbulletin ) Архитектура там ого-го, задумки глубокие. Но, говно, да, жутко неудобно шаблоны писать и монструозный движок.

VBulletin кстати не весь профиль в 1 таблице хранит, а только основную инфу. Настраиваемые(дополнительные) поля они в отдельной таблице :-)

> VBulletin кстати не весь профиль в 1 таблице хранит, а только основную инфу. Настраиваемые(дополнительные) поля они в отдельной таблице :-)

Это сделано вовсе не для ускорения работы, просто работа с основной и настраиваемой инфой устроена по разному.