Вопрос по БД

Как лучше поступить, я хочу создать нечто подобное livejournal.com.
Как известно на этом сервисе, как и в любой соц сети есть пользователи и у каждого пользователя есть своя информация которая сохраняется у БД.
Как лучше:
1. Чтобы информация отдельных пользователей была у БД специально созданных для него;
2. Одна БД со всеми данными от всех пользователей (все сохраняется в общих таблицах);
3. Одна БД со всеми данными от всех пользователей (каждому пользователю свои таблицы, шаблон тот же, префиксы разные (app_users, ne_users и т.д.) ).

А вот если представить себе, что плодить одинаковые сущности это вредно. Как поступить в этом случае?

Естественно одна база и одна таблица - пункт 2. Как Вы представляете, например, получение сводной информации по тысячам таблиц или баз, или обновления структуры, или добавление модулей? Это не говоря о том, что физические сервера будут слабо поддерживать столько баз.

Pilat66, ну зачем было так сразу палить контору? Можно ведь было намеками подвести к правильному ответу.

4. если собираетесь делать своими силами - начать с чего-нибудь попроще, а так, конечно же, искать команду на проект (и очень мноооого денег )

Цитата ("lovelas"):

Как лучше:
1. Чтобы информация отдельных пользователей была у БД специально созданных для него;
2. Одна БД со всеми данными от всех пользователей (все сохраняется в общих таблицах);
3. Одна БД со всеми данными от всех пользователей (каждому пользователю свои таблицы, шаблон тот же, префиксы разные (app_users, ne_users и т.д.) ).

Так-с, рассмотрим эти способы.

1. Этот способ самый надежный и безопасный. Если БД такого-то пользователя будет повреждена или взломана, то БД других пользователей с большей вероятностью будут в порядке. Но при этом на проект в целом накладывается ряд функциональных ограничений.
2. Этот способ самый лучший с точки зрения производительности, и он наиболее функционален.
3. Это аналогично способу 1 с точки зрения безопасности, то есть можно разным пользователям дать раздать пермиссии только на их таблицы, и т.д., но это немного менее надежно. И те же функциональные ограничения присутствуют.

Это в теории. На практике же способы 1 и 3 имеют право на жизнь лишь если у Вас всего несколько пользователей, и нет сквозных запросов по всем пользователям (например, ка френдленту-то смотреть...). В настоящее время повсеместно применяется способ 2, именно этот способ лучше и выбрать в данном случае.

Я, кстати, реализовал комбинацию пунктов 1 и 3 недавно - не для пользователей, а для версий наборов данных, которых было немного. Пока не начал переходить на DBIx::Class, всё казалось правильным, логичным и быстрым.

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

По пункту 3 реализовано разделение данных пользователей в WordPress MU ( multi-user ):

wpmu_1_posts
wpmu_1_comments
wpmu_1_options
...

Я бы выбрал 2-й.
Остальные извращение ...

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

Цитата ("storier"):

По пункту 3 реализовано разделение данных пользователей в WordPress MU ( multi-user ):

wpmu_1_posts
wpmu_1_comments
wpmu_1_options

Да, но сама система WPMU плохая, что подтверждает нецелесообразность выбора.