Mô hình được đề xuất để ghi nhật ký sự kiện ở cấp ứng dụng

Tôi sẽ lưu trữ các sự kiện ở cấp ứng dụng (người dùng A đã thêm, người dùng B đã cập nhật, v.v.) cho cả tiêu dùng công cộng và riêng tư.

Dưới đây là một mô hình đơn giản hóa của các bảng và các hiệp hội của chúng.

users
-------
id (PK)

event_type
-------
id (PK)
description

events
-------
id (PK)
user_id (FK)
event_type_id (FK)
created (timestamp)

Các sự kiện sẽ được báo cáo theo định dạng dòng thời gian (các sự kiện mới nhất ở trên cùng) cho mỗi người dùng.

Tôi cũng muốn thêm các thông số uri tùy chỉnh và bối cảnh sự kiện (Người dùng A đã cập nhật "Thẻ Visa của tôi").

Tôi có nhìn ra bất kỳ cạm bẫy tiềm năng nào trong thiết kế này không?

Mô hình cơ bản của bạn là tốt. Nó cung cấp cho bạn một giao điểm chuẩn, chuẩn hóa (nhiều đến nhiều) các sự kiện thuộc các loại cụ thể được liên kết với người dùng cụ thể. Không biết thêm về ý định hoặc yêu cầu của bạn, thật khó để đưa ra bất kỳ lời chỉ trích nào về mô hình.

Tôi sẽ thực hiện những quan sát này:

1. Bạn có thể sử dụng events.idcho PK của bạn trên eventsbàn nếu bạn thích. Đó có lẽ là cách mà tôi sẽ làm điều đó. Tuy nhiên, bạn có một sự lựa chọn để xem xét thực hiện PK eventkết hợp events.user_idvà event_type_id. Điều này sẽ tốt như vậy, có thể tốt hơn một chút, nếu bạn sẽ không có bảng nào khác trực tiếp tham khảo eventsbảng. Lợi thế tiềm năng phải được xem xét trong bối cảnh bạn dự định quản lý không gian cho bảng này như thế nào và các sự kiện sẽ tích lũy nhanh như thế nào. Sử dụng events.idnhư một chỉ mục phân cụm có thể tạo ra một điểm nóng. Mặt khác, sử dụng khóa ghép có thể tạo ra độ trễ dài trong phần chèn của bạn nếu bạn không quản lý trang của mình một cách chính xác.

2. Bạn đã đề cập rằng mô hình được đơn giản hóa, nhưng bạn chưa nói theo những cách nào. Một điều mà tôi muốn nói là mô hình như được trình bày cung cấp rất ít thông tin về các sự kiện. Bạn biết ai đã làm gì (và khi nào) - nhưng những gì được giới hạn trong chuỗi mô tả tĩnh. Các hệ thống ghi nhật ký sự kiện khác mà tôi đã thấy (và được xây dựng) bao gồm các địa điểm để ghi lại các chi tiết cụ thể về đối tượng của sự kiện. Nếu tôi là bạn, tôi sẽ tự hỏi mình những câu hỏi như:

   • Nó có giúp ích gì không nếu có một trường văn bản trên eventsbàn có thể chứa đầy các chi tiết cụ thể về những gì đã xảy ra trong sự kiện này?

   • Nó có giúp có các cột ghi lại trường hợp nào của một mục khác bị tác động bởi hành động (tức là: events.object_typevà events.object_id) không?

   • Có sự kiện phức tạp nào có nhiều phần nên được nhóm lại thành một sự kiện logic không? Có một lĩnh vực cho phép nhiều eventshồ sơ được gắn với nhau sẽ hữu ích?

Nếu bạn có thể cho chúng tôi biết thêm về cách bạn dự định sử dụng các sự kiện, từ góc độ thông tin có ý nghĩa như thế nào là hữu ích, tôi có thể cho bạn lời khuyên cụ thể hơn.

Một trong những ứng dụng tôi duy trì có cấu trúc tương tự nhưng thêm vào đó bằng cách có bảng application_event_type

ID,VALUE  
0,CREATE  
1,ASSIGN  
3,UPDATE  
2,DELETE  
4,UNASSIGN  
5,APPROVE  
6,MARK_AS_DUPLICATE  

và bảng tổng thể trông như thế này

CREATE TABLE APPLICATION_LOGGING  
(  
  ID                  NUMBER(9)                 NOT NULL,   
  CURRENT_USER_ID     NUMBER(9),  
  EVENT_ID            NUMBER(9)                 NOT NULL,  
  ENTRY_DATE          DATE                      NOT NULL,  
  MESSAGE             VARCHAR2(200 CHAR)        NOT NULL,  
  MESSAGE_PARAMETERS  VARCHAR2(2000 CHAR)       NOT NULL  
)  

Tôi thấy rằng đăng nhập là một cái gì đó mà nhiều người quan tâm hơn tôi mong đợi. Người quản lý muốn biết ai đã làm gì. Đối với họ, một mục nhật ký khó hiểu là không đủ. Message và Message_parameter là các chuỗi văn bản dài với quá nhiều thông tin. Tôi đã phải tạo một bảng liên kết cô đọng thông điệp và thông điệp tin nhắn sang tiếng Anh hoặc tiếng Pháp

CREATE TABLE APPLICATION_LOGGING_NEW
(
  ID                        NUMBER(10)         NOT NULL,  
  LOG_ID                    VARCHAR2(50 BYTE)  NOT NULL,  
  EVENT_ID                  NUMBER(10),   
  MESSAGE                   VARCHAR2(500 BYTE) NOT NULL,  
  LOCALE_ID                 NUMBER(10)         DEFAULT 2    NOT NULL,  
  LOG_TYPE                  NUMBER(10)         DEFAULT 1    NOT NULL,   
  DATE_CREATED              TIMESTAMP(6)       DEFAULT CURRENT_TIMESTAMP NOT NULL,  
  CREATED_BY_USER_ID        NUMBER(9)          DEFAULT 355  NOT NULL,
  DATE_LAST_MODIFIED        TIMESTAMP(6)       DEFAULT CURRENT_TIMESTAMP NOT NULL,
  LAST_MODIFIED_BY_USER_ID  NUMBER(9)           DEFAULT 355 NOT NULL  
)  

Một cơ sở dữ liệu khác mà tôi làm việc có đăng nhập rộng rãi. Bất cứ khi nào bạn "nhìn" vào một cái gì đó chèn là xong. Đây có vẻ là một tính năng tuyệt vời nhưng bảng ghi nhật ký hiện gấp ba lần kích thước của năm bảng lớn nhất. Truy vấn và chèn bảng này có ảnh hưởng nhất định đến hiệu suất.

Ghi nhật ký là một nghệ thuật tốt: quá nhiều và bạn có thể ảnh hưởng đến hiệu suất, không đủ và bạn không thể trả lời một câu hỏi hợp lý. Đó là giá trị đầu tư thời gian để tìm sự cân bằng phù hợp.