Рекомендации по выпуску инвентаризации в базе данных

Я создаю приложение для продажи билетов, которое отслеживает количество билетов и деактивирует их, когда конкретный билет распродан.

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

Текущий поток:

  • Пользователи добавляют items к order как line_items, а order помечается как выполненное при успешной оплате.
  • items имеет quantity_available, обновленный на основе их line_items
  • Я периодически просматриваю orders без каких-либо действий в течение > 20 минут, удаляю эти ордера line_item и обновляю quantity_available.

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

И наоборот, это связывает инвентарь на 20 минут, что может привести к потере продаж, когда шоу почти распродано.

Любое понимание будет высоко оценено. Спасибо.


inventory database-design ticket-system
person Alex Dunae    schedule 25.02.2011    source источник
comment
В качестве продолжения: я подумал о подсчете line_items во время выполнения, чтобы получить текущий доступный инвентарь, как обсуждалось здесь . Мне казалось, что выполнение этого запроса для каждой отдельной транзакции будет медленным, и кэширование количества будет лучше. Хотя вполне возможно, что я ошибаюсь.   -  person Alex Dunae    schedule 25.02.2011
comment
Этого трудно избежать, однако я бы сохранял каждое бронирование/покупку, когда кто-то регистрируется, вы бы проверяли количество (r + p) против quantity_available (которое никогда не следует корректировать). Если вы этого не сделаете, у вас может быть случай, когда какой-то скрипт/процесс скорректировал число, но вы не можете понять, почему, что может привести к перепродаже или недопродаже. К вашему сведению, я запускаю несколько таких программных систем и еще не сталкивался с ситуацией, что, если кто-то хочет, но кто-то другой зарезервировал и не использует ее (хотя я тоже этого опасался)   -  person Rudu    schedule 25.02.2011

Ответы (3)


arrow_upward
6
arrow_downward

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

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

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

person Nathan DeWitt    schedule 25.02.2011
comment
Мне нравится идея предупреждений, чтобы добавить чувство срочности. Это определенно добавит немного сложности интерфейсу, но оно того стоит. - person Alex Dunae; 25.02.2011
comment
В итоге я сделал что-то вроде этого: я добавил в line_items столбец с именем affects_inventory, то есть true для выполненных и отложенных заказов и false для заброшенных заказов. - person Alex Dunae; 01.03.2011
comment
да, внешний интерфейс становится более сложным и, вероятно, AJAXy, но как потребитель я ценю такие сообщения. Это может снизить процент отказов. - person Nathan DeWitt; 01.03.2011

arrow_upward
1
arrow_downward

Мне интересно, почему вы связываете инвентарь на основе необработанного заказа? Я думаю о том, как работают такие популярные сайты, как Newegg и Amazon. Я могу создать корзину, и она будет жить бесконечно. Но это ничего не делает с моим инвентарем, это просто запись в базе данных. С Newegg я могу вернуться на сайт несколько месяцев спустя, и моя брошенная корзина все еще там (что было очень удобно для меня в прошлом).

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

person Jake Munson    schedule 25.02.2011
comment
Что происходит, когда, например, остался только один билет, и два заказа выполняются по этому билету. Теоретически они оба могут совершить платеж одновременно, и одному из них не повезет. - person Alex Dunae; 25.02.2011
comment
Вы должны были бы закодировать для этого. Если вы используете транзакции БД, вы всегда можете проверить в качестве последнего шага, чтобы увидеть, не исчерпали ли какие-либо другие заказы запасы. Если да, то откат. - person Jake Munson; 25.02.2011
comment
когда вы смотрите на маршрутизаторы, не имеет значения, какой из них вы покупаете. если вы говорите о зарезервированных местах, это очень важно. Возможно, я не захочу совершать транзакцию, если это не те места, которые я выбрал. - person Nathan DeWitt; 25.02.2011
comment
Я заметил, что ваше продолжение выше добавлено к исходному вопросу. Я бы не беспокоился о производительности для проверки инвентаря. Если вы индексируете свои таблицы, простой запрос проверки инвентаризации займет всего пару миллисекунд. Лучше иметь хорошее обслуживание клиентов, чем программировать для повышения производительности. Если производительность является проблемой, обновите оборудование (или попробуйте оптимизировать БД/код). :) - person Jake Munson; 25.02.2011
comment
О... Наверное, я недостаточно хорошо прочитал первоначальный вопрос и не понял, что мы говорим здесь о билетах на мероприятия. Я полностью согласен, в этом сценарии имеет смысл позволить пользователю зарезервировать билеты до завершения. Не обращайте внимания на мои комментарии. :) - person Jake Munson; 25.02.2011
comment
Как насчет этой идеи? Что, если вы добавите резервный этап в обработку вашего заказа. Дайте пользователю понять, что как только он достигнет этого этапа (возможно, после того, как он заполнит начальную форму и до оплаты, или, может быть, после того, как он нажмет кнопку исходного заказа), его билеты будут зарезервированы. Вы также можете сообщить в этот момент, что у них есть x минут, чтобы выполнить заказ, иначе их билеты вернутся в пул. Таким образом, все в руках пользователя. И вы продолжаете использовать процесс очистки, чтобы вернуть брошенный инвентарь. - person Jake Munson; 25.02.2011

arrow_upward
0
arrow_downward

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

Также похоже, что вам нужно подумать о том, как вы определяете «порядок». Вероятно, вам нужно ввести еще несколько шагов. Процесс прохождения заказа является «резервированием», только после оплаты он подтверждается. Таким образом, вы можете отправить запас на «резервирование» (избыточное резервирование — это нормально), и первый, кто совершит оплату, получит заказ. Остальные терпят неудачу - они должны были быть быстрее!

person Stevo    schedule 25.02.2011
comment
Я сомневаюсь, что люди окажутся на странице оформления заказа и узнают, что они были недостаточно быстры. Это может быть единственный способ, но я знаю, что как потребитель я был бы очень зол, если бы я начал заказ, пошел за своей кредитной картой и вернулся, чтобы обнаружить, что я что-то упустил. - person Alex Dunae; 25.02.2011
comment
@AlexDunae, я решил эту проблему в два этапа. сначала отметьте часы, показывая, сколько времени в минутах и ​​секундах осталось им для выполнения заказа, независимо от того, находятся ли они на последних этапах, или даже предоставляя информацию CC. во-вторых, когда заказ находится в обработке (оплата производится), ожидается ответ шлюза. Если счетчик галочек закончился и если платеж был отклонен, то покупатель информируется сообщением об ошибке, а также очищается корзина. вот так работает нормально! и для поддержания инвентаря, когда информация о платеже отправляется на шлюз, я просто отмечаю его как ожидающий оплаты - person KMX; 27.08.2013
comment
@AlexDunae, и я считаю статус ожидания платежа в зарезервированных критериях. Если платеж был отклонен, то статус станет ожидающим или отклоненным или просроченным, если счетчик тиков закончился! - person KMX; 27.08.2013