Projeto de esquema para lidar com vários gateways de pagamento


9

Essa é mais uma pergunta que requer feedback. Estou projetando um banco de dados que lida com vários gateways de pagamento. Um gateway de pagamento geralmente requer uma tabela para obter detalhes do pedido antes de efetuar o pagamento (isso é comum para todos os PGs) e uma tabela para detalhes da transação, para armazenar a resposta após o pagamento.

Agora, para lidar com vários gateways de pagamento, posso manter uma única tabela de transações, preenchendo-a com todos os campos disponíveis em todos os gateways de pagamento e um campo que diz de qual PG é essa linha;
Ou, posso criar tabelas de transação separadas para cada um dos PG com prefixo como paypal_ou bank_etc, cada um com os campos de que precisam.

Só não tenho certeza de qual é a melhor maneira de fazê-lo. Também é necessário aprendê-lo para cenários semelhantes que eu possa encontrar no futuro.


Depende da sua situação exata. Em geral, é mais barato selecionar subconjuntos de uma tabela grande do que mesclar muitas pequenas tabelas junto com o UNION. Mas há situações em que o design de pequenas mesas funciona melhor.
Walter Mitty

O que você tem até agora?
Aaron

@ BryceAtNetwork23 Por enquanto, estou lidando com dois PGs e tenho tabelas separadas para os dois. Mas tenho que adicionar mais PGs no futuro. Então, estava pensando se eu deveria continuar fazendo isso, pois tenho que continuar adicionando mais tabelas a cada vez. É uma escolha entre o aumento do número de tabelas e uma tabela com o aumento do número de colunas e registros. Estou um pouco confuso.
Bibhas

@Bibhas, É possível compartilhar conosco a solução que você usou? Estou tendo a mesma dúvida.
Marcio Mazzucato

@MarcioSimao fomos com mesa única com propriedades como paypal_transaction_id, bank_transaction_idetc. Nós não têm muitas gateways de pagamento, por isso funcionou para nós. Pode não funcionar com aqueles que apoiam muitos PGs.
Bibhas

Respostas:


7

Depende da diferença entre os dados entre os tipos de pagamento.

Para os sites que eu apoio no trabalho, temos uma tabela que armazena dados para todos os tipos de pagamento. Isso funciona para nós porque nossos tipos de pagamento são basicamente quatro tipos de cartões de crédito e pedidos de compra da empresa. A maioria dos nossos clientes paga com cartão de crédito, portanto, não há muitos desvios nos dados. Obviamente, as consultas para esses clientes de cartão de crédito sempre geram valores NULL no campo PONumber. Da mesma forma, as consultas para clientes de PO geram NULLs em todos os campos relacionados ao cartão de crédito.

Se houver muitos campos diferentes nos seus dados, você pode tentar uma tabela de transações mestre com tabelas individuais para cada gateway de pagamento. Cada tabela de tipo de gateway de pagamento teria uma chave estrangeira de transaction_id, que seria vinculada novamente à tabela de transações mestre.

Por outro lado, se todos os tipos de gateway de pagamento tiverem campos semelhantes, eu ficaria com uma tabela de transações.


11
Obrigado por esclarecer isso. Eu acho que estava bem na minha frente, mas só precisava de alguém para apontar isso. :)
Bibhas

@ BryceAtNetwork23, Se eu tiver muitos gateways, como 5 ou mais, você acha que terei dificuldades para obter os dados? Estou perguntando isso porque acho que a tabela principal de transações precisará fazer muitas junções esquerdas em cada tipo de gateway de pagamento.
Marcio Mazzucato
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.