Progettazione di schemi per la gestione di più gateway di pagamento

Questa è più una domanda che richiede feedback. Sto progettando un database che gestisce più gateway di pagamento. Un gateway di pagamento richiede principalmente una tabella per i dettagli dell'ordine prima di effettuare il pagamento (questo è comune per tutti i PG) e una tabella per i dettagli della transazione, per memorizzare la risposta dopo aver effettuato il pagamento.

Ora per gestire più gateway di pagamento, posso mantenere una singola tabella delle transazioni, riempiendola con tutti i campi disponibili da tutti i gateway di pagamento e un campo che dice da quale PG proviene quella riga;
Oppure, posso creare tabelle di transazione separate per ciascuno dei PG con prefisso like paypal_o bank_etc, ognuno con i campi di cui ognuno ha bisogno.

Non sono sicuro di quale sia il modo migliore per farlo. Devo anche impararlo per scenari simili che potrei incontrare in futuro.

database-design

— Bibhas
fonte

Dipende dalla tua situazione esatta. In generale, è più economico selezionare sottoinsiemi di un grande tavolo piuttosto che unire molti piccoli tavoli insieme a UNION. Ma ci sono situazioni in cui il design dei tavolini funziona meglio.

— Walter Mitty,

Cosa hai finora?

— Aaron,

@ BryceAtNetwork23 Per ora, sto gestendo due PG e ho tabelle separate per entrambi. Ma in futuro dovrò aggiungere altri PG. Quindi pensavo se avrei dovuto continuare a farlo, poiché devo continuare ad aggiungere più tabelle ogni volta. È una scelta tra un numero crescente di tabelle e una tabella con un numero crescente di colonne e record. Sono un po 'confuso.

— Bibhas,

@Bibhas, è possibile condividere con noi la soluzione che hai usato? Sto avendo lo stesso dubbio.

— Marcio Mazzucato,

@MarcioSimao siamo andati con un solo tavolo con proprietà come paypal_transaction_id, bank_transaction_idecc. Non avevamo troppi gateway di pagamento, quindi ha funzionato per noi. Potrebbe non funzionare con coloro che supportano molti PG.

— Bibhas,

Dipende da quanto sono diversi i dati tra i tipi di pagamento.

Per i siti che supporto al lavoro, abbiamo una tabella che memorizza i dati per tutti i tipi di pagamento. Funziona per noi perché i nostri tipi di pagamento sono fondamentalmente 4 tipi di carte di credito e ordini di acquisto dell'azienda. La maggior parte dei nostri clienti paga con carte di credito, quindi non c'è molta deviazione nei dati. Naturalmente, le query per quei clienti con carta di credito producono sempre valori NULL nel campo PONumber. Allo stesso modo, le query per i clienti PO generano NULL in tutti i campi relativi alla carta di credito.

Se nei tuoi dati sono presenti molti campi diversi, puoi provare una tabella delle transazioni principale con singole tabelle per ciascun gateway di pagamento. Ogni tabella dei tipi di gateway di pagamento avrebbe una chiave esterna di transaction_id, che rimanderebbe alla tabella delle transazioni principale.

D'altra parte, se tutti i tipi di gateway di pagamento hanno campi simili, mi atterrerei con una tabella delle transazioni.

— Aaron
fonte

Grazie per averlo chiarito. Immagino che fosse proprio di fronte a me, ma avevo solo bisogno di qualcuno che lo segnalasse. :)

— Bibhas,

@ BryceAtNetwork23, se ho molti gateway, come 5 o più, pensi che avrò difficoltà a ottenere i dati? Lo sto chiedendo perché penso che la tabella delle transazioni principale dovrà fare molti join a sinistra in ciascun tipo di gateway di pagamento.

— Marcio Mazzucato,