Привет, коллеги!
Помогите пожалуйста создать архитектуру БД для такого сервиса:
Пользователь создает сущность "Анкета", в которую он может добавлять вопросы. Задача первая: хранить анкеты. Тут вроде тривиально - таблица из двух полей "Пользователь" и "ИД анкеты".
 Вопросы могут быть четырех типов:
1. Вопрос, предполагающий ответ цифрой(float/int).
2. Вопрос, предполагающий ответ строкой(string).
3. Вопрос, предполагающий ответом выбор одного варианта ответа из нескольких предложенных.
4. Вопрос, предполагающий ответом выбор нескольких вариантов из предложенных.
Любой вопрос имеет стандартные поля: "номер в анкете", "текст вопроса" и возможно еще какие-нибудь.
Пользователь первым делом после создания анкеты создает в ней вопросы. Появляется задача вторая - хранить эти вопросы в БД. Надо сказать, что количество вариантов ответа может быть любым, т.е. заранее в таблице не получится зарезервировать кучу столбцов под варианты ответа.
Следующим этапом является сбор данных в анкету. Анкета попадает к респондентам, те отвечают на вопросы, и это тоже надо хранить в базе.
Важный момент - пользователей предполагается очень много, как и анкет, поэтому надо придумать так, чтобы вся БД не рухнула и довольно шустро ворочала данными.

Я придумал такой вариант, и его же раскритиковал:
Таблица "Пользователи", к которой по "ИД пользователя" привязывается таблица "Анкеты".
Таблица "Вопросы", в которой каждый вопрос привязывается к "ИД Анкеты". Таблица "Вопросы" состоит из следующих столбцов: "Номер в анкете", "Текст вопроса", "Тип вопроса".
Для вопросов с вариантами ответа создается еще таблица "Варианты ответов", куда заносятся собственно варианты, привязанные к таблице "Вопросы" уникальным ИД вопроса.
Последняя таблица - ответы. Содержит поля "Ид ответа", "ИД отвечающего", "К какой анкете принадлежит ответ"(к какому исследованию), "Ответ".

В этом случае у меня всего 5 таблиц:
Пользователи - достаточно маленькая таблица по сравнению с остальными.
Анкеты - тоже довольно маленькая, но в несколько раз больше чем Пользователи(если предположить, что у пользователя несколько анкет).
Вопросы - огромная таблица, в которой хранятся все вопросы всех анкет.
Варианты ответов - вероятно еще более огромная таблица, в которой хранятся варианты ответов на вопросы. А если смотреть на тренды в социологии - вопросы в большинстве своем имеют многовариантную структуру - таблица ого-го какая большая будет.
Ответы - её объем еще больше: на каждый вопрос из таблицы "Вопросы" тут есть не по одному ответу(ведь отвечающих на анкету много)

Как эту монстрскую структуру я думал оптимизировать:
1. Вместо двух типов вопроса с выборами ответа оставить один "Многовариантный вопрос" и ввести в таблицу "Вопросы" поле "Количество вариантов ответа".
2. Вместо того, чтобы хранить на каждую анкету десятки вопросов - можно хранить одно поле, в которое засовывать кодированную в JSON или XML(БД это поддерживает) информацию о всех вопросах анкеты. Так же и с ответами - хранить каждую заполненную анкету в XML в базе. Минусом такой "оптимизации" является то, что если пользователю приспичит поменять описание одного вопроса - надо будет достать из базы xml, распарсить её, исправить нужное место и записать обратно. Так же невозможно достать ответы на конкретные вопросы чтобы, например, проследить зависимость между вопросами "пол" и "возраст" - придется дергать все данные, а потом из них брать нужные.

Если я запутанно объяснил - могу завтра нарисовать диагрумму на эту структуру.
Во всяком случае мой вариант сдохнет, когда у меня будет примерно 500 пользователей, имеющих по одной анкете из 50 вопросов, и на каждую анкету будет по 1000 ответов. Тогда таблица "Ответы" будет из 25кк строк, что делает быстрый доступ к ней невозможным.

Есть еще идея: на каждую анкету заводить новые таблицы "Вопросы", "Варианты ответов" и "Ответы" - тогда они будут не особо большими.

Есть какие идеи?

Во-первых, там будут только ссылки на соотв. ИДы (ИД анкеты, ИД опрашиваемого, ИД вопроса, ИД ответа),  так что физически она будет не такой уж и большой. Да к тому же в ней синтетика-ключ нафиг не нужен.
Во-вторых, индексирование даст довольно быстрый доступ к данным. Причём, с учётом того, какая инфа оттуда будет обычно тянуться и по какому критерию отбираться, вероятно, наиболее разумны индексы по (ИД_анкеты, ИД_опрашиваемого) и по (ИД_анкеты, ИД_вопроса, ИД_ответа).
В третьих, таблицу можно и секционировать. Вероятно, по диаазону значений ИД_анкеты.

Добавлено через 1 минуту и 1 секунду

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