Projektowanie schematu do obsługi wielu bram płatniczych

To jest bardziej pytanie, które wymaga informacji zwrotnej. Projektuję bazę danych, która obsługuje wiele bram płatniczych. Bramka płatności wymaga przede wszystkim tabeli szczegółów zamówienia przed dokonaniem płatności (jest to wspólne dla wszystkich PG) oraz tabeli szczegółów transakcji, do przechowywania odpowiedzi po dokonaniu płatności.

Teraz, aby obsłużyć wiele bram płatniczych, mogę albo utrzymać jedną tabelę transakcji, wypełniając ją wszystkimi polami dostępnymi ze wszystkich bramek płatniczych i polem, które mówi, z którego PG pochodzi ten wiersz;
Mogę też utworzyć osobne tabele transakcji dla każdego PG z prefiksem podobnym paypal_lub bank_itp., Każdy z polami, których każdy potrzebuje.

Po prostu nie jestem pewien, który sposób jest najbardziej optymalny. Muszę też się tego nauczyć w podobnych scenariuszach, które mogą napotkać w przyszłości.

database-design

— Bibhas
źródło

To zależy od twojej dokładnej sytuacji. Ogólnie taniej jest wybierać podzbiory jednego dużego stołu niż łączyć wiele małych stolików razem z UNION. Ale są sytuacje, w których projektowanie małych stołów działa lepiej.

— Walter Mitty

Co masz do tej pory

— Aaron

@ BryceAtNetwork23 Na razie zajmuję się dwoma PG i mam osobne tabele dla obu z nich. Ale w przyszłości muszę dodać więcej PG. Zastanawiałem się, czy powinienem to kontynuować, ponieważ za każdym razem muszę dodawać kolejne tabele. Jest to wybór między rosnącą liczbą tabel a jedną tabelą o rosnącej liczbie kolumn i rekordów. Jestem nieco zdezorientowany.

— Bibhas

@Bibhas, Czy można podzielić się z nami rozwiązaniem, którego użyłeś? Mam te same wątpliwości.

— Marcio Mazzucato,

@MarcioSimao wybraliśmy się z jednej tabeli z właściwości, takie jak paypal_transaction_id, bank_transaction_iditp Nie mieliśmy zbyt wielu sposobów płatności, więc to działało dla nas. Może nie działać z tymi, którzy wspierają wiele PG.

— Bibhas

To zależy od tego, jak różne są dane między rodzajami płatności.

Dla witryn, które obsługuję w pracy, mamy jedną tabelę, która przechowuje dane dla wszystkich rodzajów płatności. To działa dla nas, ponieważ nasze typy płatności to w zasadzie 4 rodzaje kart kredytowych i firmowe zamówienie zakupu. Większość naszych klientów płaci kartami kredytowymi, więc dane nie zawierają dużych odchyleń. Oczywiście zapytania dla tych klientów kart kredytowych zawsze dają wartości NULL w polu PONumber. Podobnie zapytania dla klientów PO dają wartości NULL we wszystkich polach związanych z kartą kredytową.

Jeśli w twoich danych jest wiele różnych pól, możesz wypróbować jedną główną tabelę transakcji z indywidualnymi tabelami dla każdej bramki płatności. Każda tabela typów bramek płatności miałaby klucz obcy id_transakcji, który łączyłby z powrotem z główną tabelą transakcji.

Z drugiej strony, jeśli wszystkie typy bramek płatności mają podobne pola, trzymałbym się jednej tabeli transakcji.

— Aaron
źródło

Dzięki za wyjaśnienie. Myślę, że to było przede mną, ale potrzebowałem tylko kogoś, kto by to zauważył. :)

— Bibhas

@ BryceAtNetwork23, jeśli mam wiele bram, takich jak 5 lub więcej, czy myślisz, że będę miał trudności z uzyskaniem danych? Pytam o to, ponieważ myślę, że główna tabela transakcji będzie musiała wykonać wiele lewych połączeń dla każdego typu bramki płatności.

— Marcio Mazzucato,