Как валидировать информацию из mysql бд?

Question

[Павел]

есть у меня база
дата | ФИО | место работы | отработанные часы | прочие ячейки

я делаю форму через ajax отправляю все на сервер и php записываю в БД , теперь у меня стала дилема если 2 или более человек зайдут одновременно заполнять форму, они оба могут отправить данные и выйдет огромный дубль

как мне запретить добавление в БД если в определенную дату у ФИО уже есть запись?

Comments

[Vitsliputsli]

Сперва нужно определиться с логикой, т.е. как это должно обрабатываться. Мы запрещаем добавлять дубли при попытке. Мы перезаписываем данные при загрзке новых данных с той же датой. А может стоит все же делать дубль и отправлять сообщение пользователю, чтобы он уже сам разбирался, какой из вариантов корректный, а какой следует удалить.

Answer 1

[Сергей С.]

Не выйдет, если ФИО+дата - первичный ключ или уникальное поле. Причем вместо ФИО желательно использовать логины или иные значения, хранимые в сторонней таблице, чтобы Иванов И.И. и Иванов И И не были разными значениями

Comments

[Павел]

да ФИО это отдельная таблица и там только цифра будет их id , а дата только в одном формате , так что у нас по сути есть что сравнивать , вопрос только как это правильно сделать чтоб еще потом и ответит получить в виде id продублированной записи ..

[Сергей С.]

Павел, зачем Вам ID записи? Unique поля и Primary key служат,чтобы дублей не было. Просто код ошибки получаете и выдаете окошко "такая запись уже существует"

[Павел]

Сергей С., там просто форма на ~ 50 человек , вот выдаст ошибку такая запись уже есть и сиди думай какая именно )

[Сергей С.]

Павел, если человек забивает "Иванов Петр, 31 января....." и видит ошибку "Такая запись уже есть", то очевидно что Иванов Петр 31 января уже вносился. Сам текст уж как-нибудь придумаете)

[Павел]

Сергей С., я вам обрисую что у меня есть чтоб примерно понимать
в форме есть select , в который подтягивается из БД id человека , дата вносится через jquery датапикер , это все в виде таблицы , выводится сразу на всех людей которые есть , у них по умолчанию проставлено место работы для удобства заполнения .
Я через jquery ajax формирую запись

$query = 'INSERT INTO dates (user_id,dates,visited) VALUES 
(дата, ФИО, место работы,часы),
(дата, ФИО, место работы,часы),
(дата, ФИО, место работы,часы),
(дата, ФИО, место работы,часы) ....... и так за каждого человека';

[Сергей С.]

Павел, сделайте вставку через commit, отключив автокоммит. Тогда для каждой вставки можно поймать ошибку. Я бы сделал так:

$query = 'INSERT INTO dates (user_id,dates,visited) VALUES
(дата, ФИО, место работы,часы)

Для каждой записи execute, после чего в массив результатов пихаем ФИО, Дату и текст ошибки. Если ошибки нет, там пустое значение.
При возврате данных разобрать массив и вывести уведомление - дело техники.

Answer 2

[Rsa97]

Странно, конечно. Если два разных человека заполняют свои данные, то как возникнет дубль? И почему одному человеку нельзя за день поработать в нескольких местах?
А решаются такие вещи обычно установкой UNIQUE INDEX по соответствующему набору полей.

Comments

[Павел]

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

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

буду гуглить UNIQUE INDEX

Answer 3

[ThunderCat]

В принципе есть всего 2 варианта, оба варианта выше написали.
1) уникальный ключ по 2 полям
2) Селект по этим же полям и проверка на стороне ЯП на наличие записи

Оба варианта работать будут, однако я бы все же советовал бы использовать 2 вариант. Не смотря на то что вариант 2 имеет некоторую возможность коллизий(как верно заметил Rsa97), он не вызывает неоднозначности в выполнении, то есть он явно проверяет наличие строки, в то время как первый метод вызывает ошибку вставки по уникальному ключу на стороне БД, что гораздо сложнее обрабатывать. В целом ничего не мешает скомбинировать оба метода, тогда коллизий можно избежать, максимально ограничив количиство возможных ошибок предварительной проверкой.

Comments

[Rsa97]

Отловить несложно, возвращается конкретная ошибка #1169 - ER_DUP_UNIQUE.
Но есть ещё и третий вариант - блокировать таблицу на время выполнения (блокировка - чтение - возможно запись - разблокировка).

[ThunderCat]

Rsa97, ну, логика построенная на ошибках/исключениях - такое себе... С блокировкой все тоже не так однозначно, было пару критичных падений сервисов именно из-за неснявшейся блокировки(такое случается), было весело (