Сейчас я еще на этапе проектирования базы и возник простой вопрос, незнаю какое решение принять. Вообшем есть база с таблицами:

USER (first_name, last_name, gender, birthday, about, ........)
CONTACT (email, icq, msn, url, ......)
ADDRESS (country_id, state_id, city_id, street, zip, ......)
SETTINGS (design_style, receive_msg, receive_news, receive_ads, ......)

Таблицы CONTACT, ADDRESS, SETTINGS связаны с таблицей USER один к одному.
Все как бы красиво т.е. для каждой сущности отдельная таблица.
Но возможно лучше было бы не делать CONTACT, ADDRESS, SETTINGS отдельными таблицами, а все это хранить в общей таблице юзер. Т.е. сделать денормализацию.

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

Исходные и ожидаемые данные/условия :

1. База MySQL 5.1
2. Если объединить все таблицы вместе получится около 100 колонок в таблице USER
3. Ожидаемое кол-во записей ~ 5 млн. в таблице USER (если неделать объединение таблиц то каждая таблица USER, CONTACT, ADDRESS, SETTINGS будет иметь по ~5 млн.)
4. Частота выполнения запросов:
- INSERT относительно редко
- DELETE реже чем INSERT т.к. юзера будут удаляться реже чем добавляться новые
- UPDATE часто, т.е. юзер может часто изменять свои данные. Скорее всего в одной транзакции изменяться будет только одна запись в таблице.
- SELECT очень часто, потому-что при логине юзера нужен SELECT, и при поиске юзеров тоже нужен SELECT причем с большим набором условий в WHERE

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

Что посоветуте ? Объединять или нет ? Спасибо.

В том то и дело, что например для SELECT желательно, чтобы данные были сразу вместе, т.к.
ненадо делать лишние JOINы.

Но вот меня смущает UPDATE т.е. например для случая с раздельными таблицами:
Один юзер правит свои контакты в таблице CONTACT, другой юзер правит свой адресс в таблице ADDRESS, а третий юзер правит поле about в таблице USER. Потом все делают одновременно UPDATE. Т.к. таблицы раздельные то все эти три транзакции немешают друг другу.

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

Или я чтото не так думаю ? Поправьте или посоветуйте если чтото нетак в моем рассуждении.

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

авторЧестно говоря, есть сомнения, как долго объекту USER будет достаточно одного
e-mail, адреса... То бишь, хватит ли связи "1:1".

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

Насчет вдруг заказчик захочет, чтобы было много email'ов - я и заказчик и исполнитель в одном лице :)