Lưu trữ các thay đổi trên các thực thể:MySQL có phải là giải pháp thích hợp?

Nếu tôi gặp phải vấn đề mà bạn đã đề cập, tôi sẽ thiết kế bảng LOG như sau:

1. EntityName :(Chuỗi) Thực thể đang bị thao túng. (Bắt buộc)
2. ObjectId :Đối tượng đang bị thao túng, khóa chính.
3. FieldName :(Chuỗi) Tên trường thực thể.
4. OldValue :(Chuỗi) Giá trị cũ của trường thực thể.
5. NewValue :(Chuỗi) Giá trị mới của trường thực thể.
6. UserCode :Định danh duy nhất của người dùng ứng dụng. (bắt buộc)
7. TransactionCode :Mọi thao tác thay đổi đối tượng sẽ cần có mã giao dịch duy nhất (như GUID) (bắt buộc),
   Trong trường hợp cập nhật đối tượng thay đổi nhiều trường, cột này sẽ là điểm chính để theo dõi tất cả các thay đổi trong bản cập nhật (chuyển đổi)
8. ChangeDate :Ngày Giao dịch. (bắt buộc)
9. FieldType :liệt kê hoặc văn bản hiển thị loại trường như TEXT hoặc Double. (bắt buộc)

Có cách tiếp cận này
Bất kỳ thực thể (bảng) nào đều có thể được theo dõi
Các báo cáo sẽ có thể đọc được
Chỉ các thay đổi mới được ghi lại.
Mã giao dịch sẽ là điểm quan trọng để phát hiện các thay đổi của một hành động.

BTW

Store the changes in the entitychange table and then store the value 
according to its datatype in entitychange_[bool|timestamp|double|string]

Không cần thiết, trong bảng đơn, bạn sẽ có các thay đổi và kiểu dữ liệu

Use partitioning by HASH(entity_id)

Tôi sẽ thích phân vùng theo ChangeDate hoặc tạo các bảng dự phòng cho changeDate đủ cũ để được sao lưu và xóa khỏi bảng LOG chính

Should I use another database system, maybe MongoDB?

Bất kỳ cơ sở dữ liệu nào cũng đi kèm với các xác suất và nhược điểm riêng, bạn có thể sử dụng thiết kế trên bất kỳ RDBMS nào. So sánh hữu ích về các cơ sở dữ liệu dựa trên documant như MongoDB có thể được tìm thấy tại đây

hy vọng sẽ hữu ích.