платежные операции и таблица заказов? - PullRequest
1 голос
/ 12 мая 2011

Каков наилучший способ обработки платежных транзакций в базе данных?

Вот что я придумал:

Таблица заказов

  • OrderID (первичный ключ) **
  • MemberID (FK)
  • OrderTotal
  • Статус (Ожидание, Обработка Завершена)
  • Платный (0, 1)

Таблица выплат

  • PaymentID (первичный ключ)
  • OrderID (относится к таблице заказов)
  • Дата
  • Статус транзакции

Например, если в таблице Платежи есть две платежные транзакции из OrderID-123.

Один Снижение , а другой Успех

Если есть ряд Успехов , то Заказы. Оплата станет 1

Или какое решение лучше?

1 Ответ

4 голосов
/ 12 мая 2011

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

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

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

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

...