Дизайн бази даних для опитування [закрито]

Мені потрібно створити опитування, де відповіді зберігаються в базі даних. Мені просто цікаво, що було б найкращим способом реалізувати це в базі даних, зокрема необхідних таблицях. Опитування містить різні типи питань. Наприклад: текстові поля для коментарів, запитання з численним вибором та, можливо, запитання, які можуть містити більше однієї відповіді (тобто, позначте все, що стосується).

Я придумав два можливі рішення:

1. Створіть гігантську таблицю, яка містить відповіді на кожне подання опитування. Кожна колонка відповідала б відповіді з опитування. тобто SurveyID, Answer1, Answer2, Answer3

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

2. Інше, що я подумав - створити таблицю запитань та таблицю відповідей. Таблиця запитань міститиме всі запитання для опитування. Таблиця відповідей міститиме індивідуальні відповіді з опитування, кожен рядок пов'язаний із запитанням.

   Простий приклад:

   tblОпитування : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, Question

   tblAnswer : AnswerID, UserID , QuestionID , Answer

   tblUser : UserID, UserName

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

Буду вдячний за будь-які ідеї та пропозиції.

Я думаю, що ваша модель №2 чудова, проте ви можете поглянути на більш складну модель, яка зберігає запитання та заздалегідь зроблені відповіді (пропоновані відповіді) і дозволяє їх повторно використовувати в різних опитуваннях.

- Одне опитування може мати багато питань; одне питання може (повторно) використовуватись у багатьох опитуваннях.
- Один (заздалегідь зроблений) відповідь можна запропонувати на багато питань. На одне запитання можна запропонувати багато відповідей. На запитання можуть бути різні відповіді, запропоновані в різних опитуваннях. Відповідь на різні запитання можна запропонувати в різних опитуваннях. Існує відповідь "Інше" за замовчуванням, якщо людина вибирає інших, її відповідь записується у Answer.OtherText.
- Одна людина може брати участь у багатьох опитуваннях, одна людина може відповісти на конкретне питання в опитуванні лише один раз.

Мій дизайн показаний нижче.

Останній сценарій створення - за адресою https://gist.github.com/durrantm/1e618164fd4acf91e372

Сценарій та файл mysql workbench.mwb також доступні за посиланням
https://github.com/durrantm/survey

Однозначно варіант №2, також я думаю, що ви можете мати огляд поточної схеми, можливо, вам потрібна інша таблиця:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

На кожне запитання, ймовірно, буде задана кількість відповідей, з яких користувач може вибрати, тоді фактичні відповіді будуть відслідковуватися в іншій таблиці.

Бази даних призначені для зберігання великої кількості даних, і більшість масштабів дуже добре. Немає реальної потреби користуватися меншою нормальною формою, просто економити на просторі більше.

Як правило, модифікацію схеми, заснованої на чомусь, що може змінити користувач (наприклад, додавання запитання до опитування), слід вважати досить смердючим. Є випадки, коли це може бути доречно, особливо, коли ви маєте справу з великою кількістю даних, але знайте, у що ви потрапляєте, перш ніж зануритися. Маючи лише таблицю "відповідей" для кожного опитування, це означає, що додавання або видалення питань може бути дуже дорогим. , і дуже важко робити аналітику питанням-агностиком.

Я думаю, що ваш другий підхід найкращий, але якщо ви впевнені, що у вас виникне багато проблем щодо масштабу, одна річ, яка працювала для мене в минулому, - це гібридний підхід:

1. Створіть детальні таблиці відповідей, щоб зберігати відповіді на запитання, як ви описали у статті 2. Ці дані, як правило, не були б безпосередньо запитані у вашій програмі, але використовувались би для генерації підсумкових даних для таблиць звітів. Напевно, ви також хочете реалізувати певну форму архівації або виводу даних для цих даних.
2. При необхідності створіть таблицю відповідей з 1. Це можна використовувати, коли користувачі хочуть переглянути просту таблицю результатів.
3. Для будь-якої аналітики, яку потрібно виконати для цілей звітності, плануйте завдання, щоб створити додаткові зведені дані на основі даних з 1.

Це набагато більше роботи для впровадження, тому я дійсно не радив би цього, якщо ви точно не знаєте, що ця таблиця зіткнеться з масовими проблемами.

Другий підхід найкращий.

Якщо ви хочете додатково її нормалізувати, ви можете створити таблицю для типів питань

Прості речі:

• Помістіть базу даних і введіть їх на свій власний диск, але не все на C за замовчуванням
• Створіть базу даних стільки, скільки потрібно, щоб у вас не було пауз, коли база даних зростає

У нас були таблиці журналів у таблиці SQL Server з 10-ти мільйонними рядами.

No 2 виглядає добре.

Для таблиці з лише 4 стовпцями це не повинно бути проблемою, навіть з хорошими кількома мільйонами рядків. Звичайно, це може залежати від того, яку базу даних ви використовуєте. Якщо це щось на зразок SQL Server, то це не буде проблемою.

Ви, ймовірно, захочете створити індекс у полі QuestionID у таблиці tblAnswer.

Звичайно, вам потрібно вказати, яку базу даних ви використовуєте, а також орієнтовні обсяги.

Виглядає досить повно для опитування посмішки. Не забудьте додати таблицю для "відкритих значень", де клієнт може надати свою думку через текстове поле. Пов’яжіть цю таблицю із зовнішнім ключем до своєї відповіді та поставте індекси у всіх реляційних стовпцях для ефективності.

Число 2 правильне. Використовуйте правильний дизайн до тих пір, поки ви не виявите проблеми з продуктивністю. Більшість RDBMS не матимуть проблем із вузькою, але дуже довгою таблицею.

Маючи велику таблицю відповідей, сама по собі, це не проблема. Поки показники та обмеження чітко визначені, у вас має бути все добре. Ваша друга схема мені добре виглядає.

Враховуючи належний показник, ваше друге рішення нормалізується і добре підходить для традиційної системи реляційних баз даних.

Я не знаю, наскільки величезна велика кількість, але це повинно без проблем отримати пару мільйонів відповідей.

Ви можете зберігати всю форму як рядок JSON.

Не впевнений у своїй вимозі, але такий підхід спрацював би за певних обставин.