Вопрос о том, как рациональнее организовать структуру БД для сайта.

MySQL базы данных веб-программирование производительность

Меня интересует, как обычно реализуется нижеописанное на крупных ресурсах.

Итак, описание. Рассмотрим некий интернет-ресурс, на котором пользователи имеют возможность регистрироваться.
Есть набор пользователей (user1, user2, ... userN), зарегистрированных на сайте.
У каждого пользователя есть некоторый набор персональных данных, который должен храниться в БД. Для примера давайте рассмотрим простейшее:

-Заметки (notes). У каджой заметки есть имя (name) и текст (text).
-Контакты (contacts). У каждого контакта есть имя(name), адрес(address), и телефон(phone).

Если бы пользователь был только один, то решение однозначно:

-таблица notes со столбцами name, text
-таблица contacts со столбцами name, address, phone

Когда пользователей много, встаёт задача разделить данные, чтобы каждому пользователю досталось своё. Это можно сделать, насколько я вижу, двумя способами:

1. К обеим таблицам добавить столбец user и пользоваться запросами типа
SELECT * FROM notes WHERE user="user1"

2. Для каждого пользователя заводить отдельные таблицы, скажем, с именами типа "user1_notes" и "user1_contacts" и работать с ними.

Какой из этих вариантов эффективнее в плане производительности?

Предположим, у нас есть 1000 пользователей, у каждого из которых есть 1 мегабайт заметок и 1 мегабайт контактов. В первом случае получаем 2 таблицы по гигабайту. Во втором - 2000 таблиц по мегабайту. Что-то подсказывает мне, что во втором случае нагрузка на SQL-сервер будет значительно меньше...

Интересует мнение тех, кто сталкивался с таким на практике.

Примечание:
Schuster, спасибо. Почитал про индексы - проблема отпала, и создание больших общих таблиц стало очевидным.
А про мегабайтные контакты - ну эт я конечно загнул))) но только лишь для примера.
Ответы:
надо исходить из целей. Что чаще всего будет делаться на сайте? Ответь на вопрос и проанализируй при каком раскладе приходется тратить меньше ресурсов(меньшая памяти используется).
Давай взглянем на это с другой стороны: зачем во втором случае нужна база? По 2 текстовых файла на юзера - и все. БД подразумевает возможность сортировки по заданным параметрам, удобный общий поиск. Если собрался растащить по тысячам таблиц - то идея теряется. Потом, у тебя прям тысяча юзеров одновременно метнется сервер грузить? Да ни в жизнь. И мегабайтами контакты ты зря считаешь - там вопрос на пару килобайт описан. Опять же, есть такая штука как индексы, серьезно облегчающая нагрузку.


15 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.