Lược đồ thiết kế để xử lý nhiều cổng thanh toán

Đây là nhiều hơn một câu hỏi đòi hỏi thông tin phản hồi. Tôi đang thiết kế một cơ sở dữ liệu xử lý nhiều cổng thanh toán. Cổng thanh toán hầu hết yêu cầu một bảng để biết chi tiết đơn hàng trước khi thực hiện thanh toán (điều này là phổ biến cho tất cả các PG) và một bảng để biết chi tiết giao dịch, để lưu trữ phản hồi sau khi thực hiện thanh toán.

Bây giờ để xử lý nhiều cổng thanh toán, tôi có thể giữ một bảng giao dịch, nhồi vào tất cả các trường có sẵn từ tất cả các cổng thanh toán và trường cho biết PG đó thuộc hàng nào;
Hoặc, tôi có thể tạo các bảng giao dịch riêng cho từng PG với tiền tố như paypal_hoặc bank_v.v., mỗi bảng có các trường mà mỗi trường cần.

Tôi chỉ không chắc đó là cách tối ưu hơn để làm điều đó. Cũng cần phải học nó cho các kịch bản tương tự tôi có thể gặp trong tương lai.

database-design

— Yếm
nguồn

Nó phụ thuộc vào tình hình chính xác của bạn. Nói chung, việc chọn các tập hợp con của một bảng lớn sẽ rẻ hơn so với việc hợp nhất rất nhiều bảng nhỏ cùng với UNION. Nhưng có những tình huống mà thiết kế bảng nhỏ hoạt động tốt hơn.

— Walter Mitty

Bạn có gì cho đến nay?

— Aaron

@ BryceAtNetwork23 Hiện tại, tôi đang xử lý hai PG và tôi có các bảng riêng cho cả hai. Nhưng tôi phải thêm nhiều PG trong tương lai. Vì vậy, đã suy nghĩ nếu tôi nên tiếp tục làm điều này, vì tôi phải tiếp tục thêm nhiều bảng mỗi lần. Đó là sự lựa chọn giữa việc tăng số lượng bảng và một bảng với số lượng cột và bản ghi ngày càng tăng. Tôi hơi bối rối.

— Bibhas

@Bibhas, Có thể chia sẻ với chúng tôi giải pháp bạn đã sử dụng không? Tôi có cùng nghi ngờ.

— Marcio Mazzucato

@MarcioSimao chúng tôi đã đi với một bảng duy nhất với các thuộc tính như paypal_transaction_id, bank_transaction_idv.v. Chúng tôi không có quá nhiều cổng thanh toán, vì vậy nó hoạt động với chúng tôi. Có thể không làm việc với những người hỗ trợ nhiều PG.

— Bibhas

Nó phụ thuộc vào mức độ khác nhau của dữ liệu giữa các loại thanh toán.

Đối với các trang web tôi hỗ trợ tại nơi làm việc, chúng tôi có một bảng lưu trữ dữ liệu cho tất cả các loại thanh toán. Điều đó hiệu quả với chúng tôi vì các loại thanh toán của chúng tôi về cơ bản là 4 loại thẻ tín dụng và đơn đặt hàng mua của công ty. Hầu hết khách hàng của chúng tôi thanh toán bằng thẻ tín dụng, do đó, không có nhiều sai lệch trong dữ liệu. Tất nhiên, các truy vấn cho những khách hàng sử dụng thẻ tín dụng này luôn mang lại giá trị NULL trong trường PONumber. Tương tự, các truy vấn cho khách hàng PO mang lại NULL trong tất cả các lĩnh vực liên quan đến thẻ tín dụng.

Nếu có nhiều trường khác nhau trong dữ liệu của bạn, bạn có thể thử một bảng giao dịch chính với các bảng riêng lẻ cho mỗi cổng thanh toán. Mỗi bảng loại cổng thanh toán sẽ có khóa ngoại giao dịch_id, sẽ liên kết lại với bảng giao dịch chính.

Mặt khác, nếu các loại cổng thanh toán của bạn đều có các trường tương tự nhau, thì tôi sẽ gắn bó với một bảng giao dịch.

— Aaron
nguồn

Cám ơn giải thích rõ ràng. Tôi đoán nó ở ngay trước mặt tôi, nhưng chỉ cần ai đó chỉ ra. :)

— Bibhas

@ BryceAtNetwork23, Nếu tôi có nhiều cổng, chẳng hạn như 5 hoặc nhiều hơn, bạn có nghĩ rằng tôi sẽ gặp khó khăn để lấy dữ liệu không? Tôi đang hỏi điều này bởi vì tôi nghĩ bảng giao dịch chính sẽ phải thực hiện nhiều lần tham gia trái trong mỗi loại cổng thanh toán.

— Marcio Mazzucato