Conception de schéma pour gérer plusieurs passerelles de paiement

Il s'agit plus d'une question qui nécessite des commentaires. Je conçois une base de données qui gère plusieurs passerelles de paiement. Une passerelle de paiement nécessite principalement un tableau pour les détails de la commande avant d'effectuer le paiement (ce qui est courant pour tous les PG), et un tableau pour les détails de la transaction, pour stocker la réponse après avoir effectué le paiement.

Maintenant, pour gérer plusieurs passerelles de paiement, je peux soit conserver une seule table de transactions, la remplir avec tous les champs disponibles de toutes les passerelles de paiement et un champ qui indique de quelle PG provient cette ligne;
Ou, je peux créer des tables de transactions distinctes pour chacun des PG avec le préfixe comme paypal_ou bank_etc, chacun ayant les champs dont chacun a besoin.

Je ne sais tout simplement pas quelle est la façon la plus optimale de le faire. J'ai également besoin de l'apprendre pour des scénarios similaires que je pourrais rencontrer à l'avenir.

database-design Bibhas
la source

Cela dépend de votre situation exacte. En général, il est moins coûteux de sélectionner des sous-ensembles d'une grande table que de fusionner un grand nombre de petites tables avec UNION. Mais il y a des situations où la conception de minuscules tables fonctionne mieux.

Walter Mitty

Qu'avez-vous jusqu'ici?

Aaron

@ BryceAtNetwork23 Pour l'instant, je gère deux PG et j'ai des tables séparées pour les deux. Mais je dois ajouter plus de PG à l'avenir. Je pensais donc si je devais continuer à le faire, car je dois continuer à ajouter des tables à chaque fois. C'est un choix entre un nombre croissant de tables et une table avec un nombre croissant de colonnes et d'enregistrements. Je suis un peu confus.

Bibhas

@Bibhas, Est-il possible de partager avec nous la solution que vous avez utilisée? J'ai le même doute.

Marcio Mazzucato

@MarcioSimao nous sommes allés avec une table unique avec des propriétés comme paypal_transaction_id, bank_transaction_idetc. Nous n'avions pas trop de passerelles de paiement, donc cela a fonctionné pour nous. Peut ne pas fonctionner avec ceux qui prennent en charge de nombreux PG.

Bibhas

Réponses:

Cela dépend de la différence entre les données entre les types de paiement.

Pour les sites que je soutiens au travail, nous avons une table qui stocke les données pour tous les types de paiement. Cela fonctionne pour nous, car nos types de paiement sont essentiellement 4 types de cartes de crédit et de bon de commande d'entreprise. La plupart de nos clients paient par carte de crédit, il n'y a donc pas beaucoup d'écart dans les données. Bien sûr, les requêtes pour ces clients de cartes de crédit donnent toujours des valeurs NULL dans le champ PONumber. De même, les requêtes des clients PO produisent des valeurs NULL dans tous les champs liés aux cartes de crédit.

S'il y a beaucoup de champs différents dans vos données, vous pouvez essayer une table de transaction principale avec des tables individuelles pour chaque passerelle de paiement. Chaque table de type de passerelle de paiement aurait une clé étrangère de transaction_id, qui serait liée à la table de transaction principale.

D'un autre côté, si vos types de passerelles de paiement ont tous des champs similaires, je m'en tiendrai à une seule table de transactions.

Aaron
la source

Merci d'avoir clarifié cela. Je suppose que c'était juste devant moi, mais j'avais juste besoin de quelqu'un pour le signaler. :)

Bibhas

@ BryceAtNetwork23, Si j'ai plusieurs passerelles, comme 5 ou plus, pensez-vous que j'aurai des difficultés à obtenir les données? Je pose cette question car je pense que la table de transaction principale devra faire de nombreuses jointures à gauche dans chaque type de passerelle de paiement.

Marcio Mazzucato