Проектирую MySQL базу данных для хранения анкет и ответов пользователей на вопросы этих анкет. На основе данных из базы формируется JSON. Разрабатываем REST API.
Пользователь заполняет данные (name
, email
, position
, tel
...) и таким образом получает user.id
. Затем отвечает на вопросы (таблица question
) анкет (таблица survey
). В результате ответы пользователя сохраняются в таблице answer
.
Ответ пользователя может быть заранее подготовлен в таблице options
(вариант выбора, например тэг select
). А может быть не подготовлен. Поэтому кроме таблицы answer_options
, которая содержим выбранные пользователем варианты ответов (многие-к-многим) таблица answer
содержит поля:
text
(ответ на вопрос как текст),num
(ответ на вопрос как число),yn
(ответ на вопрос как логический тип).Таблица input_types
содержит тип элемента формы (например, <input type="text"/>
.
Таблица insert_types
содержит имя поля в таблице answer
(yn
, text
, num
или options
).
API выводит вопрос в таком виде:
{
"id": 1,
"label": "Годовой оборот компании?",
"placeholder": "Введите число",
"required": true,
"input_type": {
"name": "text"
},
"insert_type": {
"name": "num"
}
}
Фронт смотрит insert_type
и может отправить такой объект ответа на вопрос:
{
"user": 1,
"question": 1,
"num": 100
}
API читает объект и сохраняет в таблице answer
(свойство num
сохраняется в answer.num
)
Мне не нравится то, что фронту приходится смотреть insert_type
. Как принято сохранять ответы пользователей на открытые вопросы анкеты (заранее не подготовленные)?
Ответ пользователя это какое-то значение. То, как это значение интерпретировать, зависит от вопроса. Фронт может всегда отправлять совершенно одинаковый для любых случаев запрос с ответом:
{
"user": 1,
"question": 1,
"answerValue": "100"
}
Ответ пользователя стоит хранить в том виде, в котором он от пользователя получен (строкой). Затем это значение можно интерпретировать в зависимости от типа вопроса. Например, на вопрос о готовом обороте можно ответить 100млн
, 100m
, 100 * 10^6
. Разбираться с тем что имел ввиду пользователь надо на этапе анализа его ответа.
Однако, для построения правильного интерфейса на фронт надо отдавать тип инпута. Не стоит зацикливаться на типах инпутов HTML-форм (но посмотрите на современные типы), используйте те, которые имеют смысл в вашем опроснике.
Итого: Тип хранится в вопросе; Ответ -- просто строка; При необходимости интерпретировать ответ, смотрим тип вопроса и делаем выводы.
Айфон мало держит заряд, разбираемся с проблемой вместе с AppLab
В общем имеется одна таблица, которая собирает поисковые запросы на сайтеВ таблице есть поле самого запроса и ИД соеденения
Подскажите как решить задачку с обезличиванием личных данных клиентов в базе MySQLМоя задача состоит в том что бы при бекапе были обезличены...
У меня проблема с crud а именно update laravelОтправляю запрос выдает ошибку