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.
źródło
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.Odpowiedzi:
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.
źródło