duy trì lịch sử trong cơ sở dữ liệu

Question

Tôi đang thiết kế cơ sở dữ liệu này phải duy trì lịch sử tiền lương của nhân viên và các chuyển động trong tổ chức. Về cơ bản, thiết kế của tôi có 3 bảng (ý tôi là, có nhiều bảng hơn nhưng đối với câu hỏi này tôi sẽ đề cập đến 3, vì vậy hãy chịu đựng với tôi). Bảng nhân viên (có lương cao nhất, dữ liệu vị trí, vv), bảng lương (lương, ngày, lý do, vv) và MovementHistory (Title, Dept., comments). Tôi sẽ sử dụng LINQ để Sql, vì vậy những gì tôi đã suy nghĩ là mỗi khi nhân viên dữ liệu được cập nhật, các giá trị cũ sẽ được sao chép vào bảng lịch sử tương ứng của họ. Đây có phải là cách tiếp cận tốt không? Tôi có nên làm điều đó bằng cách sử dụng LINQ to SQL hoặc trình kích hoạt không? Cảm ơn bạn đã giúp đỡ, gợi ý hoặc ý tưởng.

Answer 1

Hãy xem http://www.simple-talk.com/sql/database-administration/database-design-a-point-in-time-architecture.

Về cơ bản, bài viết cho thấy rằng bạn có các cột sau trong bảng bạn cần phải theo dõi lịch sử -

* DateCreated – the actual date on which the given row was inserted. 
* DateEffective – the date on which the given row became effective. 
* DateEnd – the date on which the given row ceased to be effective. 
* DateReplaced – the date on which the given row was replaced by another row. 
* OperatorCode – the unique identifier of the person (or system) that created the row. 

DateEffective và DateEnd cùng cho bạn biết thời gian mà hàng là hợp lệ (hoặc thời gian mà một nhân viên ở trong một bộ phận, hoặc thời gian mà anh ta kiếm được một mức lương cụ thể).

Answer 2

Bạn nên giữ logic đó bên trong cơ sở dữ liệu: đó là lý do tại sao trình kích hoạt tồn tại. Tôi nói điều này một cách cẩn thận, tuy nhiên, vì có rất nhiều lý do để giữ nó bên ngoài. Thông thường, đặc biệt là với một công nghệ dễ dàng như LINQ-to-SQL - nó dễ dàng hơn để viết mã bên ngoài. Theo kinh nghiệm của tôi, nhiều người hơn có thể viết rằng logic trong C#/LINQ hơn có thể làm điều đó một cách chính xác bằng cách sử dụng một kích hoạt.

Trình kích hoạt nhanh - chúng được biên dịch! Tuy nhiên, chúng rất dễ bị lạm dụng và làm cho logic của bạn quá phức tạp đến mức độ hiệu suất có thể giảm đi nhanh chóng. Xem xét trường hợp sử dụng của bạn đơn giản như thế nào, Tôi sẽ chọn sử dụng trình kích hoạt, nhưng đó là cá nhân tôi.

Answer 3

Trình kích hoạt có thể sẽ nhanh hơn và không yêu cầu "người trung gian" để hoàn thành công việc, loại bỏ ít nhất một cơ hội bị lỗi.

Tùy thuộc vào cơ sở dữ liệu bạn chọn, bạn chỉ có thể sử dụng một bảng và bật OID trên bảng và thêm hai cột nữa, "gắn cờ" và "trước đó". Không bao giờ cập nhật bảng này, chỉ chèn. Thêm một trình kích hoạt để khi một hàng được thêm vào cho nhân viên #id, hãy đặt tất cả các bản ghi với nhân viên #id để có một lá cờ "cũ" và đặt hàng mới "trước đó" giá trị cho hàng trước đó.

Answer 4

Trình kích hoạt giúp cho giao diện người dùng của bạn dễ dàng di chuyển sang một thứ khác và chúng sẽ giữ cho cơ sở dữ liệu nhất quán bất kể dữ liệu được chèn/cập nhật/bị xóa như thế nào.

Bên cạnh trường hợp của bạn, tôi sẽ viết tiền lương thẳng vào lịch sử tiền lương - từ mô tả của bạn, tôi sẽ không thấy lý do tại sao bạn nên đi qua một cập nhật kích hoạt trên bảng nhân viên.

Answer 5

Tôi nghĩ điều này thuộc về cơ sở dữ liệu vì hai lý do.

Đầu tiên, tầng giữa đi và đến, nhưng cơ sở dữ liệu là mãi mãi. Năm nay Java EJBs, năm tới .NET, năm sau đó một cái gì đó khác. Dữ liệu vẫn còn, theo kinh nghiệm của tôi.

Thứ hai, nếu cơ sở dữ liệu được chia sẻ thì không cần phải dựa vào mọi ứng dụng sử dụng nó để biết cách duy trì tính toàn vẹn dữ liệu của nó. Tôi sẽ xem xét đây là một ví dụ về đóng gói của cơ sở dữ liệu. Tại sao buộc kiến ​​thức và bảo trì lịch sử trên mọi khách hàng?