Самое элегантное решение для огромных проблем

Question

Я работаю над сайтом, где пользователь может выбрать определенные даты, которые относятся к ним, например, Дата 1, Дата 2, Дата 3 и т. Д.

Каждая дата будет иметь определенные вопросы, относящиеся к ней, поэтому, если клиент отметит «Дата 1», чтобы указать, что эта дата относится к нему, он увидит группу текстовых полей, спрашивающих его о дате 1 и как она применяется. им. То же самое касается всех других дат.

Дата 1 и 2 и несколько вопросов, но у оставшихся дат только 1 вопрос.

Эти даты и их ответы будут позже использованы для создания персонализированных напоминаний для клиента и отправки ему.

Мне бы также хотелось, чтобы дизайн, который упрощает (или максимально упрощает) добавление дополнительных дат и полей.

Мой вопрос: как лучше всего хранить в базе данных все даты и их ответы, относящиеся к пользователю? Я думал, что в таблице user у меня есть столбцы boolean от Дата 1 - Последняя дата (очевидно, они на самом деле не назвали дату 1, дату 2 и т. Д.). Если для столбца «Дата 1» задано значение «0», это означает, что клиент не отмечал этот флажок, а если значение «1», то это означает, что он это сделал и ответил на вопросы.

Что касается фактического хранения дат, я рассматриваю следующие два варианта:

1) 1 таблица для каждой даты, со столбцами для каждого вопроса, задаваемого для этой даты, и столбец user_id. Поэтому в таблице Date_1 будут столбцы типа Q1_name, Q2_name и ответы на вопросы, которые задал пользователь.

Но я хочу что-то более элегантное, потому что 1) будет сложно получить ответы на все вопросы пользователя при расчете какой информации. относится к ним при отправке персонализированных писем. 2) У некоторых дат есть только 1 вопрос, поэтому было бы некрасиво создавать для них полноценную таблицу.

2) A user_answer таблица с колонками:

user_id,date_name,question_name,answer_val

2 пока кажется самым элегантным, но должно быть лучшее решение. Есть мысли?

Answer 1

Звучит так, будто вы хотите что-то вроде следующей (базовой) структуры таблицы:

• Пользователь - userId, userInfo
• Дата - dateId, dateInfo
• Вопрос - questionId, questionInfo
• UserDate - userId, dateId - здесь хранятся все даты, относящиеся к данному пользователю, и представлены отношения «многие ко многим» между пользователями и датами - у пользователя может быть много дат, а у даты может быть много пользователей.
• DateQuestion - dateId, questionId - здесь хранятся все вопросы, относящиеся к определенной дате, и представлена ​​взаимосвязь «многие ко многим» между датами и вопросами - у даты может быть много вопросов и, я полагаю, вопрос можно использовать против более чем одной даты
• UserResponse - userId, questionId, questionResponse - здесь хранятся все ответы пользователей на любые заданные вопросы. Если вам необходимо знать, к какой дате относится вопрос, предполагая, что они могут ответить на один и тот же вопрос более одного раза для нескольких дат, добавьте столбец dateId.

Answer 2

Я думаю, что вы в значительной степени получили его, единственное, что вы можете разделить имена вопросов и дат в отдельной таблице, предоставив вам следующую схему:

Пользователь : id, ... (имя, дата рождения, любимая еда и т. Д.)
DateName : id, name (назвал его DateName, поэтому не конфликтует со словом Date, что может означать что-то другое в SQL)
Вопрос : id, date_id, text
UserAnswer : user_id, question_id, answer_val

Нет необходимости разделять их, но для этого есть три причины: 1. Поиск по целым числам (например, question_id) в отличие от текста (например, question_name) намного быстрее, поскольку целые числа меньше и имеют фиксированный размер. 2. Если вы измените текст на вопрос (например, чтобы исправить орфографическую ошибку), вам нужно всего лишь изменить одну запись в вопросе, а не в каждой строке. 3. Поскольку вы сохраняете каждый бит текста только один раз, вы экономите много места. Хранение 1000 дюймов меньше, чем хранение 1000 строк. Ну, пока строки длиннее нескольких символов, которые есть.

Кроме того, я думаю, что это может сработать довольно хорошо.

Answer 3

Вариант 2 кажется близким к хорошему решению, но я бы заменил date_name и question_name на date_id и question_id.
Оптимальное и простое решение, позволяющее добавлять новые вопросы и даты, выглядит следующим образом:
1. Таблица дат с полями date_id, title, date.
2. Таблица вопросов с полями question_id, date_id, title (и, возможно, введите ответ и описание).
3. Таблица ответов с question_id и answer.

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