Sử dụng kích hoạt hoặc giao dịch MySQL?

Tôi muốn hỏi ý kiến ​​của bạn trong việc sử dụng kích hoạt hoặc giao dịch MySQL trong một trang web.

Thật ra tôi có một paymentbảng lịch sử với - UserId | OperationId | Comment | Credits | Sign (debit or credit). Vì vậy, mỗi hoạt động thanh toán được chèn vào bảng này.

Tuy nhiên, sẽ rất tốn thời gian khi tính toán mỗi lần tổng số tiền tín dụng của người dùng mỗi khi anh ta thực hiện hành động. Vì vậy, tôi nghĩ có lẽ nên giữ tổng số tiền tín dụng cho mỗi người dùng trong một profilebảng người dùng .

Đây là vấn đề. Làm cách nào tôi có thể chắc chắn rằng tổng số tiền tín dụng từ profilebảng sẽ được đồng bộ hóa với các hoạt động từ paymentbảng lịch sử?

Tôi nghĩ rằng sử dụng 2 phương pháp:

• MySQL kích hoạt hoặc
• giao dịch được mã hóa trong mã nguồn

Cái nào đáng tin cậy hơn? Nếu tôi có cơ sở dữ liệu lớn (hơn 100.000 người dùng) thì sao?

Bạn có bất cứ đề nghị để làm điều này?

Công cụ BD MySQL là InnoDB.

Không nghi ngờ gì, tôi sẽ loại trừ các yếu tố kích hoạt và tuyệt đối giữ các giao dịch.

Triggers, về bản chất, thủ tục được lưu trữ. Hành động của họ hầu như khó quay trở lại . Ngay cả khi tất cả các bảng bên dưới là InnoDB, bạn sẽ trải nghiệm một khối lượng theo tỷ lệ của các khóa hàng được chia sẻ và sự gián đoạn khó chịu từ các khóa hàng độc quyền. Đó sẽ là trường hợp nếu các trình kích hoạt đang thao túng các bảng với INSERT và UPDATE bị đình trệ để thực hiện MVCC nhiệm vụ nặng nề bên trong mỗi lệnh gọi đến trình kích hoạt .

Kết hợp điều này với thực tế là các giao thức xác thực dữ liệu phù hợp không được triển khai trong Ngôn ngữ thủ tục lưu trữ của MySQL . Business Intelligence vẫn ổn khi có trong cơ sở dữ liệu với điều kiện Ngôn ngữ thủ tục được lưu trữ có thể xử lý môi trường giao dịch . Là một DBA của MySQL, tôi phải thành thật nói rằng đó không phải là trường hợp của MySQL. Oracle (PL / SQL), PostgreSQL (PL / pgSQL) và SQL Server (T-SQL) có lợi thế này so với MySQL.

Liên quan đến các giao dịch, MySQL có InnoDB là công cụ lưu trữ tuân thủ ACID chính (công cụ lưu trữ Deafult trong MySQL 5.5). Nó có khả năng phục hồi sự cố tuyệt vời và tuân theo các giao thức tuân thủ ACID.

Tôi sẽ chọn transacitons hơn kích hoạt mỗi lần.

Tôi đồng ý với đánh giá của Rolando. Logic nghiệp vụ của bạn sẽ nằm trong ứng dụng của bạn và sẽ thay đổi cơ sở dữ liệu một cách giao dịch.

Tất nhiên, việc mở rộng tới 100.000 người dùng phụ thuộc vào ứng dụng của bạn và lưu lượng cơ sở dữ liệu mà nó tạo ra. Với MySQL dưới một tải ghi giao dịch nặng, bạn có thể sớm phải đối mặt với gánh nặng của việc bảo vệ và / hoặc sao chép tập dữ liệu của bạn để duy trì phản ứng ứng dụng chấp nhận được.

Tuy nhiên, có những lựa chọn thay thế để bảo vệ MySQL. Một trong số đó là Clustrix (chủ nhân của tôi), là một hệ thống cơ sở dữ liệu SQL đơn lẻ hiệu năng cao có khả năng mở rộng song song. Đây là một hệ thống cơ sở dữ liệu được nhóm lại, thể hiện chính nó như là một máy chủ MySQL duy nhất. Mở rộng cơ sở dữ liệu được mô tả trong luồng này một cách liền mạch tới 100.000 người dùng trong một phiên bản Clustrix duy nhất sẽ không yêu cầu shending và không có logic ứng dụng bổ sung.

Câu trả lời tốt từ Rolando.

Ngoài ra - Không nên sử dụng kích hoạt cho logic, vì một vài yếu tố kích hoạt liên quan đến nhau sau này, mọi thứ sẽ trở nên khó hiểu nhanh. Một tập hợp các hướng dẫn tốt đẹp trong một thủ tục được lưu trữ hoặc thủ tục phía máy khách có thể vượt qua logic nghiệp vụ rõ ràng hơn một loạt các logic ẩn trong cơ sở dữ liệu. Cũng có những hạn chế đối với các kích hoạt liên quan đến bảng mà chúng được kích hoạt từ đó - vì vậy bạn có thể thấy mình đang phân tách logic của mình ở hai nơi khác nhau ..

Ngoài ra - bạn có thể tìm cách tối ưu hóa tại thời điểm các tính toán này xảy ra trong máy chủ logic nghiệp vụ của mình, trong khi đó một trình kích hoạt sẽ kích hoạt mỗi lần. Bạn sẽ thấy mình tắt trình kích hoạt, cập nhật bảng và sau đó kích hoạt lại trình kích hoạt - điều đó cũng có nghĩa là bạn cần đặt logic kích hoạt trong mã đó .

Ngoài ra - bạn không cần phải có tất cả logic trong phần logic nghiệp vụ của mã - bạn có thể muốn thực thi tính toàn vẹn của bảng bằng cách sử dụng các thủ tục được lưu trữ. Điều này có thể bắt đầu một giao dịch, thực hiện nhiều cập nhật của bạn và khiến mọi thứ trở lại tốt đẹp nếu có gì đó không thành công. Bằng cách đó, ai đó nhìn vào cơ sở dữ liệu có thể thấy logic để chèn một đơn đặt hàng, ví dụ. Điều này ít quan trọng hơn trong thế giới ngày nay vì các dịch vụ web có thể là giao diện truy cập duy nhất vào db; nhưng trong trường hợp nhiều tệp thực thi có quyền truy cập vào DB thì điều này có thể rất lớn.

Ngoài ra - dù sao bạn cũng sẽ có giao dịch - bạn sẽ không thực hiện các kích hoạt của mình mà không có ... đúng không? Vì vậy, thật tốt khi biết cách bắt đầu một giao dịch; làm một số thứ; và sau đó kết thúc một giao dịch. Nếu bạn thấy mẫu này trong mã của mình, một đoạn mã nữa sử dụng nó sẽ nhẹ trên tải nhận thức. Một trình kích hoạt, nếu bạn nhớ rằng nó ở đó, sẽ buộc bạn phải suy nghĩ khác về các giao dịch bị ảnh hưởng bởi trình kích hoạt, đặc biệt là nếu các bảng khác được kéo vào cũng có thể có các trình kích hoạt.

Về cơ bản, giữa một công việc định kỳ thường xuyên (hoặc công việc đại lý cơ sở dữ liệu) và các thủ tục được lưu trữ tốt, bạn có thể hoàn thành 99% những gì bạn muốn. 1%; suy nghĩ lại về dự án.