2012-06-15 3 views
7

매월 (또는 매주) 고정 금액에 대한 반복 결제가 포함될 응용 프로그램을 작성 중이며 가입이 취소 될 때까지 사용할 수 있습니다. 고객은 여러 기간을 미리 지불 할 수 있습니다. 그는 구독을 취소 한 다음 미지급 기간 후에 되돌아 올 수 있습니다. 기간이 만기가되면 알려주는 Sistem이 필요합니다. 반복 결제 데이터베이스 디자인

그래서 나는

어느 한 응용 프로그램의 종류에왔다, 데이터베이스를 (어쩌면 데이터베이스 문제가 아니라 프로그래밍이 아니다) 설계하는 방법에 내 머리를 타는거야? 어떤 접근법이 취해 졌습니까?

답변

2

나는 당신이 그것을 복잡하게 생각합니다.

pk id_subscription 
fk id_user 
fl_type (maybe there are different subscriptions, with different prices) 
dt_in 
dt_out 

많은 지불에 테이블 지불 하나 명 가입을 만듭니다 :

pk id_payment 
fk id_subscription 
fl_type (card, payment order, something else) 
fl_status (generated, sent, confirmed, canceled because of subscription canceled, canceled because of something else, etc) 
dt_generated 
dt_sent 
dt_confirmed 
dt_canceled 
[I think you will need another fields to follow and confirm the payment, but it depends of your payment model) 

pk id_user 
nm_user 
fl_status (active, canceled, pendent, etc) 

테이블 가입에게 많은 가입 한 사용자를 만듭니다 :

테이블 사용자를 만듭니다 이제 특정 시간에 매일 실행되는 몇 가지 로봇을 제작해야합니다.

액티브 클라이언트와 각각의 최종 지불액을 얻은 경우 실제 확정일보다 x 일 이상 최종 지급액이 생성 된 경우 새 지불이 생성되어야하는지 알 수 있습니다 (이는 선불, 후불 등). 예인 경우 새로운 지불 주문이 생성됩니다.

로봇이 주문과 함께 이메일을 보내거나 (다음으로 플래그로 표시).

다른 로봇이 귀하의 지불 모델을 사용하여 지불을 확인합니다.

물론, 각 사용자 상태가 결제가 이루어지지 않아 취소되거나 판사에게 전송 될 때까지 로봇을 유지해야하므로 모델을 매우 잘 정의해야합니다. 할 일이 많지만 큰 문제는 없습니다.

ps : 더 복잡한 시스템이되면 데이터베이스가 유지되고 필요한 모든 정보를 갖게되며 모든 주문에 대한 로그가 생깁니다. 날짜가 있기 때문에 각각의 상황을 알 수 있습니다. 지위. 만기일 수, 하루에 지불 할 금액, 하루에 지불 할 금액, 2 일 후에 지불 할 금액 등을 계산할 수 있습니다.

+1

지불을 인보이스와 지불 테이블로 분리하고보다 표준 필드 이름 ('id', 'subscription_id'등)을 사용하는 것이 좋습니다. Agile Toolkit은 다른 데이터베이스 디자인 레이아웃 (http : // agiletoolkit)을 처리 할 수 ​​있습니다.org/learn/understand/model/add – romaninsh

4

나는 당신이 디자인에 너무 영리 해지고 그것을 지나치게하려고 노력하고 있을지도 모른다라고 생각한다. 비즈니스 문제를 생각하면 각 지불 간격은 실제로 송장입니다. 인보이스 표를 만들고 예약 된 작업에 각 계정의주기와 해당 기간 동안 활성 상태인지 여부에 따라 특정 간격으로 송장을 삽입하는 것이 아닌가.

실제 송장 행을 보유하면 고객으로부터 지불을 요청할 때 참조 할 수있는 InvoiceID를 얻고 각 대금 청구에 대해 개별적으로 지불 상태를 추적 할 수 있습니다.

때때로 단순합니다.