Проектирование БД для сайта знакомств

Всем привет! Заголовок многообещающий, но на деле вопросы простые. Их два.

1) Как бы вы организовали хранение личной инфы о пользователе? В одной таблице или же в нескольких?
Ситуация в том, что полей может быть очень много

логин
пароль
емаил
телефон
страна
город
пол
возраст
скайп
аська
рост
вес
дети
отношение к курению
...

Рассматриваю два варианта:

Одна таблица. Плюсы: простота выборки. Минусы: большая нагрузка на сервер. Если пользователей ~N млн., а нам надо выбрать только тех, кто online, вычитая из текущей даты дату последного клика, то при такой структуре будут тормоза ого-го.

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

Что посоветуете?

И вопрос №2, посложнее.
2) Как бы вы организовали хранение фотографий на сервере?
На эту тему есть множество статей. Пока склоняюсь к варианту с хабра, когда путь вычисляется по айди.
На многих сайтах используют несколько серверов для изображений. Где про это можно почитать? На данный момент смотрю в сторону WebDAV.
Вариант с хранением изображений в БД не рассматриваю.

-----
Удобный сервис для хранения файлов

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

2) Все то же самое что и в первом ответе, только применительно к теме второго вопроса.

-----
Шта? Репозиторий?

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

Структура данных должна быть подчинена нуждам приложения.
Если полей будет много (а их будет в итоге в несколько раз больше чем вы указали) выносите в отдельные таблицы данные, которые запрашиваются не часто.
В базовой таблице пользователя держите только самые часто запрашиваемые поля: логин, пароль, почта (в зависимости от требований приложения). Для дополнительных данных, которые запрашиваются реже (например, - только на странице профиля) - сделайте связанную таблицу, для множественных строк к одному пользователю - строго отдельная связанная таблица: vocabulary_gallery, user_notepad и т.п.
Также для вас может быть актуально вывести в отдельную таблицу, например, user_online список пользователей на сайте, что ускорит операцию вывода и изменения этого параметра при большом количестве полей в таблице user и при большой частоте этой операции.
В конечном счете не все можно заложить на этапе проектирования, тестирование для такого, предположительно, нагруженного проекта все равно потребуется и последующие корректировки в т.ч. на уровне архитектуры уровня данных.

(Отредактировано автором: 24 Декабря, 2012 - 09:23:34)

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

-----
Удобный сервис для хранения файлов