Проектування БД тестувальної системи. NEED HELP!!!

Проектую БД для тестувальної системи. Є такі таблиці Test, Questions, Answers. Після спілкування зі знайомими задумався над моїм проектуванням тому що кількісь записів в таблиці Answers може досягати 100000. Сутність Answer це текст відповіді, id відповіді, id тесту + інші поля. Коли користувач відповідає на запитання то на серевер відсилається стрічка з відповіддю. Ця стрічка може бути в різних форматах — це може бути id правильної відповіді; масив id коли правильних відповідей кілька; стрічка в певному форматі; стрічка в довільному форматі.

Застряг перед наступним вибором:

1.Залишити поточне проектування

Якшо я залишу поточне проектування то прийдеться ще додатково писати парсер на сервері для розпарсання відповіді користувача + напевно кешувати ту частину відповідей до яких я буду звератись шоб відіслати користувачу наступне запитання з відповддями. Також при поточному плануванні перевірка відповіді на правильність вимагатиме звертань до громіздкої таблиці Answers. З іншого боку представлення кожної відповіді як окремої сутності є дуже зручним для формування таблиці результатів пояснень і т.д.

2.Не виносити Answers в окрему сутність, тобто не створювати для неї таблицю в бд, а для кожного тесту в базі (таблиця Questions) додати ше одне поле, яке буде містити текст всіх відповідей як одне ціле, і ше одне поле яке буде містити правильну відповідь.

В цьому випадку вибираючи з бд запитання для певного тесту я зразу ж виберу і відповіді. Також перевірка відповіді на правильність зведеться до порівняння стрічки яку я отримав від користувача з тою що є в таблиці Questions

Прохання людей які проектували потрібні речі або просто знають як це зазвичай робиться висловити свою думку.Наперед дякую!!!

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
ДБА як такого немає, тому що це проект на курсову роботу.

Може хтось порадити джерела де можна почитати про проектування індексів для таблиць та звязків. Базові знання теорії є але хотілось б практичні поради

Те саме, якщо правильно спроектуєш таблиці-звязки-індекси (а десь і робота ДБА має бути).
К-ть записів в 100 000 не критично, на мою думку і 1 млн теж (якщо це не Access чи *.dbf).

Я б подумав над варіантами самих тестів, їх різновиди можуть не вписатись в такі прості схеми

Digr, а коли буде вибиратися група записів з використанням порівняня where по 2 полях... яка тоді буде швидікість?

100000 — дуже багато?
SQL> set timing on
SQL> select count (*) from “тут просто табличка документів”;
COUNT (*)

142314
Executed in 0, 015 seconds

SQL>

Для запобігання надлишковості даних. 1НФ вимагає атомарність даних в комірках таблиці.

Не розростеться Answers — так розростеться Questions.

Иван Мазепов, а можете пояснити чому 1, адже таблиця Answers може розростися до дуже великих розмірів (порядка 100000)...?

Однозначно варіант 1, відповідь можеш пересилати в XML.

десь так
yuml.me/2adfcfb1
в табличці Answers будуєш кластерний індекс по [test_result_id]
в табличці ResultVariants кластерний індекс по Answers_id.
в табличці Answers поле ще для «кастом ввода (число слово) »
В табличці Variants поле логічного типу (правильна відповідь)
В табличці Questions — можна поле правильна кастомна відповідь.
Можна добавити «фіктивні» Variants до запитання такі, що не показуються і їх помітити як правильна відповідь.
тоді А в запитання тільки тип правільної відповіді (указати всі чи одну з). Можна з економити на 1 полі в табличці Questions
(я б мабуть так зробив).

поле Custom таким чином економити не доречно.

Підписатись на коментарі