Лучшие практики для выпуска инвентаря в базе данных - PullRequest
5 голосов
/ 25 февраля 2011

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

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

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

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

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

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

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

Ответы [ 3 ]

6 голосов
/ 25 февраля 2011

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

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

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

0 голосов
/ 25 февраля 2011

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

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

0 голосов
/ 25 февраля 2011

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

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

...