Chiến lược ghi nhật ký kiểm tra

Question

Tôi đang cố gắng quyết định phương pháp tốt nhất để ghi nhật ký kiểm tra trong ứng dụng của mình. Lý do chính cho nhật ký là báo cáo chuỗi sự kiện (thay đổi).

Tôi có một hệ thống cấp bậc của Đối tượng, tôi cần tạo báo cáo khi có điều gì đó thay đổi trên bất kỳ phần nào của phân cấp đó, vào ngày sau.

Tôi nghĩ rằng tôi có ba lựa chọn:

1. Có một bản ghi cho mỗi bảng và do đó phù hợp với hệ thống phân cấp của các đối tượng sau đó tạo ra một cái nhìn cho báo cáo.
2. Làm phẳng cấu trúc phân cấp và khử chuẩn hóa bảng, giúp báo cáo dễ dàng hơn - câu lệnh chọn đơn giản.
3. Có một bảng nhật ký và có một bản ghi cho mỗi thay đổi làm cho báo cáo khó khăn hơn nhưng linh hoạt hơn để thay đổi.

Tôi hiện đang nghiêng về phía tùy chọn 1.

Answer 1

Một log kiểm toán về cơ bản là một danh sách tự thời gian của các sự kiện đã xảy ra, người thực hiện những sự kiện này, và những gì các sự kiện đã.

Tôi nghĩ rằng chế độ xem phẳng sẽ tốt hơn vì có thể dễ dàng đặt hàng và truy vấn. Vì vậy, tôi đang nghiêng về phía lựa chọn của bạn # 2/# 3.

Bao gồm những thứ như loại giao dịch, thời gian, id người dùng, mô tả về những gì đã thay đổi và thông tin thích hợp khác liên quan đến sản phẩm của bạn.

Bạn cũng có thể thêm mọi thứ vào sản phẩm của mình theo thời gian và bạn sẽ không cần phải liên tục sửa đổi mô-đun nhật ký kiểm tra của mình.

Answer 2

Nếu nó dành cho mục đích kiểm toán, tôi sẽ sử dụng phương tiện nối thêm thực sự chứ không phải là bảng/bảng trong cùng một db.

Bạn đề xuất nó cho mục đích lịch sử thay đổi - trong trường hợp này tôi sẽ cơ cấu lại ứng dụng/db của bạn để ghi lại các sự kiện thực tế ngay từ đầu chứ không phải trạng thái hiện tại.

Answer 3

Tôi sẽ sử dụng (2) và (3): tạo một bảng cho tất cả các mục Kiểm tra.

Chế độ xem phẳng là tốt, miễn là làm việc thêm làm phẳng không ảnh hưởng đến hiệu suất.

Answer 4

Bạn có thể xem xét một khuôn khổ AOP để trợ giúp việc này. Nó sẽ cho phép bạn chèn chức năng ghi nhật ký vào đầu hoặc cuối của bất kỳ/tất cả các phương thức. Nếu bạn đi xuống con đường này, nó có thể giúp xác định những gì sẽ có ý nghĩa để lưu trữ dữ liệu nhật ký.

Answer 5

Tôi phải nói chuyện với chủ đề này mặc dù nó cũ.

Thường là một ý tưởng tồi khi chỉ có một bảng kiểm tra vì bạn sẽ tạo ra các sự cố về khóa trong cơ sở dữ liệu khi mọi thứ chạm vào bảng đó. Sử dụng các bảng kiểm toán riêng biệt cho mỗi bảng.

Cũng là một ý tưởng tồi để ứng dụng thực hiện kiểm tra. Kiểm toán phải được thực hiện ở cấp cơ sở dữ liệu hoặc bạn có nguy cơ mất một số thông tin. Dữ liệu không chỉ thay đổi từ các ứng dụng trong hầu hết các cơ sở dữ liệu; sẽ không có ai thay đổi giá của tất cả các sản phẩm của họ cùng một lúc từ giao diện người dùng khi bạn cần tăng 10% cho tất cả 10.000.000 sản phẩm. Kiểm toán phải nắm bắt tất cả các thay đổi không chỉ là một số thay đổi. Điều này nên được thực hiện trong một kích hoạt trong hầu hết các cơ sở dữ liệu (SQL server 2008 có chức năng kiểm tra được xây dựng).Một số thay đổi tiềm ẩn tồi tệ nhất (nhân viên phạm tội hoặc muốn phá hủy dữ liệu) cũng thường xuyên từ những nơi khác ngoài ứng dụng, đặc biệt nếu bạn cho phép truy cập cấp bảng cho người dùng (Bạn không nên làm gì trong bất kỳ cơ sở dữ liệu tài chính nào thông tin cá nhân). Kiểm toán từ ứng dụng sẽ không bắt được điều này. Các nhà phát triển thường quên rằng trong việc bảo vệ dữ liệu của họ, các nguồn bên ngoài không phải là mối đe dọa duy nhất.