Проектирую БД (тестирование бд: mysql, среда разработки 1С: битрикс) возникает вопрос с производительностью с быстротой поиска данных, с физическим размером БД на винчестере.

помогите выбрать из нескольких строгих возможных вариантов, как лучше:

1) иметь в таблице 25млн. записей или иметь 5тыс таблиц, с 5000тыс записей. (Хранить для каждого пользователя свою таблицу, 5тыс пользователей) (таб_ Ринф)

2) иметь в таблице 25 000 000 000 записей или иметь 5тыс таблиц, с 5000тыс записей. (Хранить для каждого пользователя свою таблицу, 5тыс пользователей) (таб Ротв)


Решаю вопрос о создании динамически таблиц.
Пожалуйста помогите найти ответ на эти вопросы. Спасибо.

Второй лучше, первый вроде как не будет точен.

если вчитаться в формулировку, то это одно и тоже, не пойму тогда сути вопроса, просто в одном пункте идет словами "млн" в другом представлено ноликами

Что там проектировать если в битриксе уже есть своя структура? Дополнительные таблицы не связаные с ядром и модулями?


Варианты равнозначны


В битриксе всегда так

Это сообщение отредактировал(а) $дмитрий - 8.11.2011, 20:25

То есть, нет разницы между формулировками или так только для битрикса?

Здесь два вопроса, как лучше поступить для первого вопроса вариант 1 или 2, и для второго вопроса вариант 1 или 2

Для первой:
1) иметь 1 таблицу с 25 000 000 записями или 
2) иметь 5 000 таблиц, с 5 000 записями в каждой таблице (Хранить для каждого пользователя свою таблицу, 5тыс пользователей) 



А это для другой :
1) иметь 1 таблицу с 25 000 000 000 записями или 
2) иметь 5 000 таблиц, с 5 000 000 записями в каждой таблице. (Хранить для каждого пользователя свою таблицу, 5тыс пользователей) 

Это сообщение отредактировал(а) Norfonzor - 9.11.2011, 13:44

Norfonzor, 5000 таблиц - это уже будет ошибкой проектирования. это чисто мое мнение, так что смотри сам.

Будет ли "нормально" работать БД при кол-ве записей равной 25 000 000 000 ?

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

Скажите, Партиционирование таблиц может решить мои проблемы?

ссылка на статью: http://habrahabr.ru/blogs/webdev/66151/

При установке решения на сервер спросить у пользователя примерное "ожидаемое кол-во записей" (вычисляить исходя из кол-ва пользователей, числа тестов в БД)

далее, исходя из кол-ва записей определить кол-во логических частей max_log_ch
ввести поле id_log_ch, указывающее в какой логической части будет хранится информация о записи
при занесении новой записи, проверять заполненность последней заполненной логической части id_max_zapoln_log_ch, в случаи ее заполненности записывать запись в следующую логическую часть:  увеличивая id_log_ch+1 

Верный ли такой подход?

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


Обычно так не делают. Как лучше поступить вам, из ваших объяснений - не ясно.

Техническое задание 
«Разработка модуля педагогического тестирования на базе «1С:Битрикс»

Необходимо разработать программный продукт (далее ПП) модуль педагогического тестирования на базе «1С: Битрикс» . В ПП должна быть предусмотрена возможность добавления различных типов тестов: обычный, адаптивный, модульный и др. В каждом из которых предусмотрен свой интерфейс форм, задач и особенностей.

Типы тестов:
Типы тестов должны добавляться и при необходимости удаляться в качестве модулей.
В разрезе каждого типа теста уполномоченный пользователь (администратор ПП) должен иметь возможность создавать новые тесты. После публикации теста, запрещается его редактирование.

Возможности всех, в конкретном случаи теста:
В тест должно быть предусмотрено:
1)    Добавлять неограниченное число вопросов. (уточнение: ограничение по типу данных)
2)    Добавлять неограниченное число ответов для каждого вопроса. (уточнение: ограничение по типу данных)
3)    Иметь возможность создавать вопросы следующих типов:
a.    Для вопросов части А 
i.    Один вариант ответа
ii.    Несколько вариантов ответа
iii.    Сопоставление правильных вариантов
iv.    Правильная последовательность частей ответа
b.    Для вопросов части B
i.    Написание собственного ответа на вопрос
4)    В ходе прохождения тестирования вопросы и, в каждом из которых, ответы должны выводиться в случайном порядке.
5)    ПП должен хранить подробную информацию о пройденных тестах.
6)    К каждому вопросу, при создании теста, должна быть возможность добавлять подсказку. Во время прохождения теста, при необходимости, скрытую по умолчанию подсказку, экзаменуемый мог бы посмотреть ее со снятием с него определенного балла, в случаи успешного ответа на этот вопрос.
7)    В тестировании должна быть предусмотрена возможность выставлять результирующий балл в зависимости от процента правильно отвеченных вопросов за каждый тест.
8)    Ответ на вопрос засчитывается, если истинно отвеченный все пункты вариантов ответа.
9)    Устанавливать ограничение по времени прохождения теста и времени ответа каждого  вопроса.
10)    В тесте должно предусмотрено деление вопросов по разделам.
11)     ПП должен иметь возможность выводить отчеты, список отчетов указан в файле Формы.xlsx, в разделе Отчеты.

12)     Для каждого теста после прохождения должна храниться следующая (общая) информация:
a.    Информация об экзаменуемом 
b.    Информация об экзаменаторе, проверившем тест, если это необходимо.
c.    Дата прохождения теста
d.    Сколько раз проходился конкретный тест, конкретным студентом
e.    Балл части А, балл части B, (указывается максимальный, если тест проходился несколько раз)
f.    Время прохождения теста
g.    Статус проверки экзаменатором (проверен/не проверен)
h.    Сообщение от экзаменатора о результатах теста.
13)    Для каждого теста должна храниться следующая (общая) информация:
a.    Тип теста
b.    Наименование теста
c.    Информация о рекомендуемой специальности для прохождения теста
d.    Информация о рекомендуемом предмете для прохождения теста
e.    Информация о сотруднике, создавшем тест
f.    Дата создания
g.    Кол-во вопросов
h.    Дополнительная информация о тесте
i.    Максимально время прохождения теста
j.    Текст вступления экзаменуемому перед прохождением тестирвоания
k.    Максимальный процент неправильных ответов после которых происходит прерывание теста.
l.    Период действия теста, период времени в которое возможно прохождение теста.
14)    Для каждого типа теста должна храниться следующая (общая) информация:
a.    Наименование типа теста
b.    Разработчик типа теста
c.    Текущая версия типа теста
d.    Номер версии с которой возможно обновление
e.    Дополнительна информация о тесте
15)    Информация об экзаменуемых
a.    ФИО
b.    Информация о учебной группе
c.    Пароль доступа
16)    Информация об экзаменаторах
a.    ФИО
b.    Пароль доступа
c.    Право администрирования

Схема данных


Расчет кол-ва записей в таблицах

Norfonzor, я так понимаю страшнее всего выглядит табилца Рответы.
Какие аналитические запросы к ней предполагаются?
Будет ли необходимость выбирать, скажем студенов, давших ответ X на вопрос Y?
С какой целью вообще хранится эта информация? Штоб была лишь? Для разбора полетов, если вдруг чо? или же по ней действительно будет считаться какая то аналитика?

Если старая информация нужна лишь изредка(например только для построения отчетов) имеет смысл архивировать эти данные

Отчеты: