Diseño de esquemas para manejar múltiples pasarelas de pago

Esta es más una pregunta que requiere comentarios. Estoy diseñando una base de datos que maneja múltiples pasarelas de pago. Una pasarela de pago requiere principalmente una tabla para los detalles del pedido antes de realizar el pago (esto es común para todos los PG), y una tabla para los detalles de la transacción, para almacenar la respuesta después de realizar el pago.

Ahora, para manejar múltiples pasarelas de pago, puedo mantener una sola tabla de transacciones, rellenándola con todos los campos disponibles de todas las pasarelas de pago y un campo que dice de qué PG es esa fila;
O bien, puedo crear tablas de transacciones separadas para cada PG con prefijo como paypal_o bank_etc., cada uno con los campos que cada uno de ellos necesita.

No estoy seguro de cuál es la forma más óptima de hacerlo. También necesito aprenderlo para escenarios similares que pueda encontrar en el futuro.

database-design

— Bibhas
fuente

Depende de tu situación exacta. En general, es más barato seleccionar subconjuntos de una tabla grande que fusionar muchas tablas pequeñas junto con UNION. Pero hay situaciones en las que el diseño de tablas pequeñas funciona mejor.

— Walter Mitty

¿Qué tienes hasta ahora?

— Aaron

@ BryceAtNetwork23 Por ahora, estoy manejando dos PG y tengo tablas separadas para ambos. Pero tengo que agregar más PG en el futuro. Entonces estaba pensando si debería continuar haciendo esto, ya que tengo que seguir agregando más tablas cada vez. Es una elección entre un número creciente de tablas y una tabla con un número creciente de columnas y registros. Estoy un poco confundido.

— Bibhas

@Bibhas, ¿es posible compartir con nosotros la solución que utilizó? Estoy teniendo la misma duda.

— Marcio Mazzucato

@MarcioSimao elegimos una sola tabla con propiedades como paypal_transaction_id, bank_transaction_idetc. No teníamos demasiadas pasarelas de pago, así que funcionó para nosotros. Podría no funcionar con aquellos que admiten muchos PG.

— Bibhas

Depende de cuán diferentes sean los datos entre los tipos de pago.

Para los sitios que apoyo en el trabajo, tenemos una tabla que almacena datos para todos los tipos de pago. Eso funciona para nosotros porque nuestros tipos de pago son básicamente 4 tipos de tarjetas de crédito y órdenes de compra de la compañía. La mayoría de nuestros clientes pagan con tarjetas de crédito, por lo que no hay mucha desviación en los datos. Por supuesto, las consultas para esos clientes de tarjetas de crédito siempre arrojan valores NULL en el campo PONumber. Del mismo modo, las consultas para clientes de PO generan NULL en todos los campos relacionados con la tarjeta de crédito.

Si hay muchos campos diferentes en sus datos, puede probar una tabla de transacción maestra con tablas individuales para cada pasarela de pago. Cada tabla de tipo de pasarela de pago tendría una clave externa de transacción_id, que se vincularía de nuevo a la tabla de transacción maestra.

Por otro lado, si todos sus tipos de pasarela de pago tienen campos similares, entonces me quedaría con una tabla de transacciones.

— Aaron
fuente

Gracias por aclarar eso. Supongo que estaba justo frente a mí, pero solo necesitaba que alguien lo señalara. :)

— Bibhas

@ BryceAtNetwork23, si tengo muchas puertas de enlace, como 5 o más, ¿cree que tendré dificultades para obtener los datos? Pregunto esto porque creo que la tabla de transacciones maestra tendrá que hacer muchas combinaciones restantes en cada tipo de pasarela de pago.

— Marcio Mazzucato