Держите идентификатор записи для проблемы с системой тикетов

Question

ОК, у нас есть специальная система заявок, разработанная на PHP / PostgreSQL. Как это работает сейчас, когда информация вводится, нажмите кнопку Отправить, номер билета отображается. Что бы они хотели, номер билета показан, введите информацию, нажмите «отправить».

Теперь я знаю, что могу просто создать пустую запись и использовать этот идентификатор записи, а затем выполнить обновление при отправке пользователем.

Я хотел знать, будет ли лучший / альтернативный способ сделать это?

Некоторые ключевые моменты:

• идентификатор записи ПК, автоинкременты
• Идентификаторы записи должны быть в порядке, без пропуска идентификаторов записи

Проблема в том, что конечный пользователь может запустить процесс идентификатора заявки, а не щелкнуть «Отправить», что приведет к пустой записи. Что может быть лучшим способом продолжить.

есть идеи или это лучший подход?

EDIT: Я понимаю все трудности и то, что мне нужно сделать, чтобы выполнить запрошенное действие, похоже, я просто собираюсь иметь дело с пустыми записями. Это не должно случаться часто, но я хотел посмотреть, сталкивался ли кто-нибудь с этим раньше. Спасибо за ввод

Answer 1

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

Существует проблема: когда пользователь 1 запускает билет, он получает, например, номер 234, после этого пользователя 2 запускатакже билет и получить номер 235, но когда пользователь 1 отменяет свой билет, то номер 234 пропускается

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

ps: я не видел ни одной системы билетов, которая показывает вам окончательный номер билета в начале создания нового билета ...

Answer 2

Практического способа сделать это не существует.

Не имеет смысла блокировать таблицы или использовать транзакции, так как приложение должно ждать дополнительного пользовательского ввода.Это означает, что билеты с информацией будут иметь промежутки между ними.Это глупое требование со стороны клиента.Ваши менеджеры должны были сделать лучшую работу, объяснив, почему получение номера билета впоследствии - путь (условия гонки):

Для получения следующего идентификатора автоинкремента требуется доступ к ресурсу.Это означает, что должен быть контроль над этим ресурсом.Представьте себе реализацию этого подхода в гастрономе.Один человек берет число и решает, чего он хочет.Другой человек пытается схватить номер.Вы должны как-то остановить их (блокировка таблиц), иначе ваши номера могут выйти из строя, если первый человек уйдет!Это, конечно, глупый способ вести бизнес.Если первый человек решит ничего не заказывать, он сможет просто выбросить билет (у вас есть более 4 миллиардов билетов - и вы можете даже увеличить его - так что все будет в порядке).

Answer 3

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

Надеюсь, это поможет.

Answer 4

Вы можете сделать что-то вроде Алгоритм Hi-Lo , хотя это сводит на нет вашу вторую ключевую точку, если вы не используете новый столбец для хранения HiLo

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

В противном случае у вас не будет проблем с незавершенными билетами или создайте задание cron, которое очищает незаконченные билеты.

1. Создание новой таблицы, например старой таблицы
2. Вставка в новую таблицу всех данных из старой таблицы, исключая пустые записи
3. Обновление таблицы с использованием имени новой таблицы
4. Удалите старую таблицу
5. Потяните вниз переменную, чтобы выяснить, какую таблицу использовать при запросах к таблице (я знаю, это раздражает)

Это работает на большихмасштаб, хотя, несмотря на гадость с кодом.