Как проще хранить информацию?

Question

[Денис Букреев]

К примеру, в БД есть таблица с пользователями
У каждого пользователя есть какие-то данные, ничем не ограничиваемые по количеству (они могут занимать две строки в таблице, могут сотню строк, а могут и тысячу)

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

Answer 1

[Егор Стаховский]

Множество мелких таблиц под каждого пользователя?
Самый простой (и самый некрасивый) способ - определить необходимый минимум для каждого пользователя, выделить этот минимум в поля таблицы, а остальное хранить в большом текстовом поле с примечаниями (этот способ остался глубоко в 90-х).
Второй способ - сделать отдельную таблицу, в которой данные будут представлены в виде userID, key, value, где key будет кодировать значение некоторого свойства. Этот способ более элегантный, но по скорости выполнения ударит, да.
Еще есть вариант с сериализацией нужных данных в массив вида key:value - и данные можно хранить вместе с пользователями.
Но это все касается реляционных БД. А вообще, синонимом "плавающей" структуры уже давно стали NoSQL-базы. Конкретные СУБД и общие механизмы описаны во множестве статей.

Answer 2

[Melkij]

В одной партицированной таблице.

Comments

[Денис Букреев]

Мощный сервер сможет минимизировать скорость запроса?

Мне интересно как Вконтакте реализует это в отношении записей на стене, у них конечно структура намного сложней того, чего я хочу, но все же похоже

Каждый пользователь имеет неопределенное количество записей, неужели все в одном месте хранится?

[Егор Стаховский]

Денис Букреев: у них нереляционная самописная БД. Об этом говорили на выступлении в 2010 - profyclub.ru/docs/103