Khi nào một bảng cơ sở dữ liệu nên sử dụng dấu thời gian?

Đầu tiên, tôi nghĩ có lẽ câu hỏi này thuộc về trao đổi cơ sở dữ liệu, nhưng tôi nghĩ nó liên quan rộng rãi đến một giải pháp lập trình nói chung hơn là cơ sở dữ liệu. Sẽ chuyển sang trao đổi cơ sở dữ liệu nếu mọi người nghĩ rằng đó là tốt nhất.

Tôi đã tự hỏi khi một bảng cơ sở dữ liệu nên có dấu thời gian được tạo và cập nhật?

Câu trả lời rõ ràng đầu tiên là nếu bất kỳ logic kinh doanh nào cần biết khi nào một cái gì đó được cập nhật (như ngày hoàn thành giao dịch, v.v.) thì nó phải đi vào.

Nhưng những gì về trường hợp logic kinh doanh không? Ví dụ: tôi có thể nghĩ về các kịch bản trong đó sẽ rất hữu ích khi biết ngày giờ các hàng thay đổi để giúp tìm lỗi, ví dụ như một số logic nghiệp vụ đang thất bại và nhìn vào các hàng cơ sở dữ liệu liên quan có thể xác định rằng một hàng đang được cập nhật trước đó một hàng khác gây ra lỗi.

Với trường hợp sử dụng này, sẽ rất hợp lý khi cung cấp cho mỗi bảng một bản cập nhật và tạo dấu thời gian (ngoại trừ các bảng enum tầm thường nhất sẽ không được cập nhật bởi bất kỳ phần nào của ứng dụng).

Đưa cho mỗi bảng một dấu thời gian chắc chắn là một cách tuyệt vời để nhanh chóng phá hỏng cơ sở dữ liệu (mặc dù có thể sai).

Vì vậy, khi nào một bảng cơ sở dữ liệu nên sử dụng tạo và cập nhật dấu thời gian?

Để quản lý cơ sở dữ liệu tốt hơn và toàn diện hơn và thực hành khôn ngoan nhất là làm như vậy.

Đầu tiên, nhiều khả năng là một nhà phát triển, bạn muốn theo dõi các giao dịch và / hoặc các hoạt động của cơ sở dữ liệu để phát triển và dễ dàng truy tìm các lỗi và lỗi trên mã của bạn bất cứ khi nào nó liên quan đến cơ sở dữ liệu của bạn.

Ngoài ra, bất cứ khi nào bạn cần theo dõi các hoạt động được thực hiện trên cơ sở dữ liệu của bạn cho mục đích thống kê .

Một điều khác, thường xảy ra là có thể trong thời gian này bạn không cần phải theo dõi các hoạt động cơ sở dữ liệu của mình, nhưng nhiều khả năng bạn sẽ làm trong tương lai. Nó sẽ cần thời gian của bạn ngày hôm nay, nhưng sẽ mua cho bạn nhiều hơn trong tương lai .

Là một người vừa là kẻ săn trộm (nhà phát triển) vừa là người chơi trò chơi (DBA), tôi ngạc nhiên khi nhiều người vẫn không thấy giá trị trong việc này và coi đó là sự phình to.

Chỉ cần đặt:

Đối với bất kỳ bảng nào có bản ghi được thêm (nhưng không bao giờ được cập nhật), ví dụ: thông tin đăng nhập, v.v. Tôi sẽ xem xét thêm cột DATE_CREATED.

Đối với bất kỳ bảng nào có bản ghi được thêm và cập nhật, tôi sẽ xem xét thêm cột DATE_CREATED và cột DATE_UPDATED.

Tôi đã làm việc ở nhiều nơi trong đó DATE_CREATED và DATE_UPDATED được bao gồm trong mỗi bảng theo mặc định như một phần của thiết kế.

Đối với các cơ sở dữ liệu lớn hơn với hàng triệu / tỷ hàng trong đó cập nhật cơ sở dữ liệu đã diễn ra trong vài ngày, chúng tôi cũng đã thêm một cột SOURCE cho một số bảng theo dõi nồi dữ liệu nào gây ra cập nhật, ví dụ như nguồn cấp dữ liệu của bên thứ 3, cập nhật người dùng, sửa đổi DBA, làm sạch dữ liệu, vv

Cách câu hỏi được diễn đạt, bạn đang yêu cầu một danh sách các điều. Tôi sẽ mạo hiểm không trả lời trực tiếp câu hỏi của bạn, nhưng trả lời khi nào bạn nên sử dụng giải pháp thay thế.

Tôi có thể nghĩ về các kịch bản trong đó sẽ thực sự hữu ích khi biết ngày giờ các hàng thay đổi để giúp tìm lỗi

Nó sẽ hữu ích hơn để có một bản ghi của tất cả các bản cập nhật cho một bản ghi nhất định? Chỉ cần biết bản cập nhật cuối cùng, có thể không đủ thông tin. Nhật ký này có thể được đặt trong một bảng riêng biệt. Sẽ thuận tiện hơn khi theo dõi các thay đổi từ một số bảng trong cùng một tệp nhật ký (không nhất thiết phải là bảng). Điều này ngăn một số truy vấn kết hợp lớn của tất cả các thay đổi bảng để có được tổng hợp. Điều này cũng có lợi cho việc xử lý sự cố bằng cách giúp bạn xem bản ghi nhiều sự kiện hơn trong hệ thống của mình.

Ngoài ra: Bạn phải xem xét cả người dùng. Họ có thể không biến nó thành một trường hợp kinh doanh, nhưng khi bạn có người dùng thiếu kinh nghiệm hoặc những người trong văn hóa doanh nghiệp nơi họ không bao giờ mắc lỗi người dùng và muốn luôn đổ lỗi cho máy tính, mọi cách ghi nhật ký sẽ giúp bao gồm cả ngày cập nhật trên bảng. Trong trường hợp này, bạn cũng có thể muốn có trường Update_UserID.

Bảng cơ sở dữ liệu phải bao gồm các mẫu tạo và sửa đổi khi một trong hai điều sau là đúng:

1. Bảng đại diện cho một bản ghi chính của một số hoạt động do người dùng cung cấp. Nếu người dùng thực hiện X và bạn có cả a Table_Xvà a Table_Ylà nhiều con Table_X, Table_Ythì đó không phải là bản ghi chính và do đó không cần thêm các trường.
2. Khi bạn có nhu cầu vĩnh viễn, tạm thời hoặc định kỳ để theo dõi hệ thống . Nếu bạn có nhu cầu kiểm tra Table_Ychỉ được cập nhật khi Table_Xđược cập nhật, các trường theo dõi bổ sung có thể hỗ trợ.

Lưu ý rằng cả hai đều không độc quyền; bạn có thể tiếp tục và thêm chúng ở mọi nơi theo mặc định và chỉ bỏ qua khi cần để điều chỉnh hiệu suất.

Ý kiến ​​cá nhân:

Tôi không thấy giá trị trong một modifiedcột.

created, tuyệt đối, nên được thêm vào mỗi bảng cơ sở dữ liệu trừ khi có lý do đặc biệt để không làm điều đó. Có rất nhiều giá trị khi có nó ở đó.

Tuy nhiên, updateddường như là một sự lãng phí. Tại sao không đi toàn bộ con lợn, tạo hai bảng cơ sở dữ liệu, một bảng chỉ định ID tài liệu và một phiên bản tài liệu khác. Trong một trường hợp rất đơn giản

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Sau đó chọn mới nhất versioncủa documentbạn muốn. Bằng cách này, bạn không chỉ lưu mỗi ngày sửa đổi - không chỉ ngày cuối cùng - mà bạn còn giữ mọi phiên bản của tài liệu đó. Đối số duy nhất chống lại nó thực sự là dung lượng ổ cứng, nhưng chắc chắn khi bạn hiểu rõ về việc bạn đang sử dụng dung lượng ổ cứng nào - trong hầu hết các trường hợp, bạn thậm chí còn bận tâm hơn về việc phiên bản dữ liệu