여러 지불 게이트웨이를 처리하기위한 스키마 설계


9

이것은 피드백이 필요한 질문입니다. 여러 결제 게이트웨이를 처리하는 데이터베이스를 설계하고 있습니다. 지불 게이트웨이는 대부분 지불하기 전에 주문 세부 사항에 대한 테이블 (모든 PG에 공통 임) 및 지불 후 응답 저장을위한 트랜잭션 세부 사항에 대한 테이블을 필요로합니다.

이제 여러 지불 게이트웨이를 처리하기 위해 단일 지불 테이블을 유지하여 모든 지불 게이트웨이에서 사용 가능한 모든 필드와 해당 행이 어느 PG인지 나타내는 필드로 채워 넣을 수 있습니다.
또는 내가 좋아하는 접두사와 PG의 각각에 대해 별도의 트랜잭션 테이블을 만들 수 있습니다 paypal_또는 bank_각각 그들 각각이 필요로하는 분야를 갖는 등.

어느 것이 가장 적합한 방법인지 잘 모르겠습니다. 또한 앞으로 나올 비슷한 시나리오에 대해서도 배울 필요가 있습니다.


정확한 상황에 따라 다릅니다. 일반적으로 UNION과 함께 작은 테이블을 많이 병합하는 것보다 하나의 큰 테이블의 하위 집합을 선택하는 것이 저렴합니다. 그러나 작은 테이블 디자인이 더 나은 상황이 있습니다.
Walter Mitty

지금까지 무엇을 했습니까?
Aaron

@ BryceAtNetwork23 지금은 두 개의 PG를 처리하고 있으며 둘 다 별도의 테이블이 있습니다. 그러나 앞으로 더 많은 PG를 추가해야합니다. 매번 더 많은 테이블을 계속 추가해야하기 때문에이 작업을 계속 해야하는지 생각했습니다. 증가하는 테이블 수와 증가하는 수의 열 및 레코드가있는 하나의 테이블 중에서 선택합니다. 조금 혼란 스러워요.
Bibhas

@Bibhas, 사용한 솔루션을 우리와 공유 할 수 있습니까? 나는 같은 의심을 가지고 있습니다.
Marcio Mazzucato 2016 년

우리가 같은 특성을 가진 하나의 테이블로 갔다 @MarcioSimao paypal_transaction_id, bank_transaction_id등이 우리를 위해 일했다, 그래서 우리는 너무 많은 지불 게이트웨이를하지 않았다. 많은 PG를 지원하는 사람들과는 작동하지 않을 수 있습니다.
Bibhas

답변:


7

결제 유형간에 데이터가 얼마나 다른지에 따라 다릅니다.

직장에서 지원하는 사이트의 경우 모든 지불 유형에 대한 데이터를 저장하는 하나의 테이블이 있습니다. 우리의 지불 유형은 기본적으로 4 종류의 신용 카드와 회사 구매 주문이기 때문에 우리에게 효과적입니다. 대부분의 고객은 신용 카드로 지불하므로 데이터에 많은 편차가 없습니다. 물론 해당 신용 카드 고객에 대한 쿼리는 항상 PONumber 필드에 NULL 값을 생성합니다. 마찬가지로 PO 고객에 대한 쿼리는 모든 신용 카드 관련 필드에서 NULL을 생성합니다.

데이터에 서로 다른 필드가 많은 경우 각 지불 게이트웨이마다 개별 테이블이있는 하나의 마스터 트랜잭션 테이블을 시도 할 수 있습니다. 각 지불 게이트웨이 유형 테이블에는 외래 키 transaction_id가 있으며 마스터 트랜잭션 테이블에 다시 연결됩니다.

반면에 지불 게이트웨이 유형이 모두 비슷한 필드를 가지고 있다면 하나의 거래 테이블을 고수합니다.


1
정리해 주셔서 감사합니다. 나는 그것이 내 앞에서 옳았지만 그것을 지적 할 누군가가 필요했다. :)
Bibhas

@ BryceAtNetwork23, 5 개 이상의 게이트웨이가 많은 경우 데이터를 얻는 데 어려움이 있다고 생각하십니까? 마스터 트랜잭션 테이블이 각 지불 게이트웨이 유형에서 많은 왼쪽 조인을 수행해야한다고 생각하기 때문에 이것을 묻고 있습니다.
Marcio Mazzucato 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.