Сочетание вставки и удаления SQL

Question

Хорошо, вот вопрос

У меня есть три стола

events
- id
- name

questions
- id
- event_id
- name

answers
- id
- question_id
- description

При создании формы добавления я могу просто искать все вопросы, относящиеся к определенному событию, и отображать вопросы в одной форме HTML.

Но рассмотрим сценарий редактирования. Менеджер событий может своевременно добавить или удалить некоторые вопросы из события. Поэтому в таком случае, когда пользователь пытается отредактировать уже опубликованный ответ, я генерирую HTML-форму с новыми вопросами в виде пустого поля, а существующие ответы являются предварительно заполненными полями ввода. Как я могу справиться с отправкой этой формы?

Когда пользователь отправляет запрос, должен ли я удалить все прошлые ответы и сделать ВСТАВКУ в таблице ответов для всех значений ответов? или это хорошая практика, чтобы сначала обновить существующие ответы и вставить только новые значения?

Первое очевидно проще с DELETE, затем INSERT. Хотя позже это несколько утомительно. Проблема с прежним решением заключается в том, что идентификатор таблицы ответов будет увеличиваться каждый раз.

Answer 1

Некоторые люди предпочитают подход удаления / вставки, потому что, как вы говорите, он проще.

Лично я думаю, что подход обновления / вставки / удаления, хотя и больше работы, является более правильным.

Если вы делаете обновления, вы можете иметь контрольный журнал изменений для определенного элемента. Просто вставьте / удалите, либо сложнее, либо просто невозможно иметь такую ​​связь и историю.

Что касается того, как обрабатывать отправку формы, для полей, которые можно обновить (т. Е. Они являются существующими записями), вам нужно как-то идентифицировать поле. Лично я просто кодирую что-то вроде первичного ключа в имени поля.

Если вы сделаете это, вы, конечно, должны убедиться, что у вас нет дыры в безопасности, проверив, что предоставленный идентификатор действителен и разрешено редактирование, т.е. никогда не доверяйте клиенту.

Это может принимать форму:

<input type="text" name="name_117" value="Some value">
<input type="text" name="name_118" value="Some other value">
<input type="text" name="name_1243" value="Yet another value">

и вам нужно обработать все входные параметры, декодировать идентификатор и действовать соответственно.

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

Answer 2

Согласен с постом Cletus, пишу отдельно по дополнительной причине и идее:

Подход удаления / вставки имеет проблему параллелизма, когда ваш сайт получает большой трафик. Кто-то может сделать вставку после удаления, и вы получите несколько списков ответов для каждого пользователя.

MySQL поддерживает синтаксис ON DUPLICATE KEY UPDATE . Это может быть простой способ объединить вставку и обновление, если у вас есть соответствующий первичный ключ.

Answer 3

Приложения для онлайн-викторин обычно блокируют тест после его запуска. Грязная проблема - иметь дело с законченными наборами ответов, а не с изменяющимся определением вопросов. Если ваше приложение справится с этим, я бы предпочел не допускать изменения вопросов после первой публикации события.

Answer 4

Во-первых, идентификатор ни в коем случае не должен использоваться, поэтому игнорирование приращения является хорошим напоминанием.

Я бы предпочел разобраться с первичным вопросом, однако, в принципе, при прочих равных условиях. Собственно ли пользователь устанавливает другой набор вопросов со своими правками? Затем сохраните их как новый набор. Или оригинальный набор предназначен для сохранения своей концептуальной идентичности? Затем обновите / удалите / вставьте. Который, кажется, больше имеет место.

С точки зрения обеспечения целостности набора вопросов / ответов, я думаю, что сессии несут такую ​​ответственность. Вы должны рассмотреть вопрос о том, чтобы задать вопрос, сопоставленный с вопросом, связанным с сеансом.