2010-05-04 39 views
9

Tôi đã thấy nhiều kiểu dáng cơ sở dữ liệu có cột sau kiểm toán trên tất cả các bảng ...Tại sao chúng ta cần cột kiểm tra trong bảng cơ sở dữ liệu?

  • Created By
  • Tạo DateTime
  • cập nhật bởi
  • Upldated DateTime

Từ một quan điểm Tôi thấy các bảng từ chế độ xem sau ...

  • Entity Bàn:
    • Tốt ứng cử viên cho các cột Audit)
  • Bàn tham khảo:
    • cột Kiểm toán có thể hoặc không cần thiết. Trong một số trường hợp thông tin cập nhật cuối cùng không phải là ở tất cả các yêu cầu bởi vì kỷ lục là không bao giờ được sửa đổi.)
  • liệu tham khảo Bàn
    • Giống như Nước Tên, Entity Nhà nước vv ... cột Kiểm toán có thể không cần thiết bởi vì những thông tin này được tạo ra chỉ trong thời gian cài đặt hệ thống, và sẽ không bao giờ bị thay đổi.

Tôi đã thấy nhiều nhà thiết kế một cách mù quáng đặt tất cả các cột kiểm toán để tất cả các bảng, là thực hành này tốt, nếu có gì có thể là lý do ...

Tôi chỉ muốn biết vì với tôi nó có vẻ phi logic. Thật khó cho tôi để tìm ra lý do tại sao họ thiết kế db của họ theo cách này? Tôi không nói họ sai hay đúng, chỉ muốn biết TẠI SAO?

Bạn cũng có thể gợi ý cho tôi, nếu có một kiểm toán patter hoặc giải pháp có sẵn thay thế ...

Cảm ơn và chúc

+3

Tên quốc gia BTW thay đổi, bạn nên làm mới định kỳ. – HLGEM

+0

@HLGEM +1! Ngoài ra, các thành phố, làng mạc ... bạn phải dành thời gian để giữ dữ liệu tham chiếu địa lý hiện tại –

+0

Câu hỏi ở đây là cần phải đặt các cột kiểm tra trên bảng ngay cả khi bạn biết nó sẽ không bao giờ thay đổi? –

Trả lời

1

Nhiều ứng dụng được phát triển sử dụng một số ngôn ngữ OOP trong đó thường là một lớp học như BusinessObject có chứa thông tin hữu ích thường được nhận thấy như các trường kiểm toán như vậy. Không phải tất cả các thực thể lớp con có thể cần nó, nhưng nó có nếu chúng thực hiện. Vì chi phí của db nhỏ và cơ hội mà khách hàng có thể yêu cầu một thống kê lẻ khác dựa trên các trường kiểm toán, tốt hơn là nên có chúng xung quanh hơn là không có chúng. Nếu một cái gì đó đại diện cho một danh sách tĩnh của thông tin như tên quốc gia tôi thường sẽ không đặt nó trong db ở tất cả - kiểu dữ liệu liệt kê được tạo ra chỉ cho các mục đích như vậy.

5

Kiểm tra dữ liệu là kiểm soát nội bộ bắt buộc đối với nhiều hệ thống kinh doanh (xem Sarbanes Oxley vì lý do tại sao). Nó phải ở cấp cơ sở dữ liệu để đảm bảo rằng tất cả thay đổi được chụp đặc biệt là trái phép.

Ngay cả với các bảng tra cứu, một thay đổi trái phép có thể làm hỏng hệ thống của bạn và do đó điều quan trọng là phải biết ai đã thay đổi và khi nào.Khi đặc biệt quan trọng vì nó giúp các dbas biết cách lấy lại một bản sao lưu để khôi phục thông tin vô tình hoặc thay đổi một cách độc hại.

Chúng tôi muốn nghĩ rằng tất cả nhân viên của chúng tôi đều đáng tin cậy, nhưng nhiều dữ liệu cá nhân và những thay đổi độc hại để tiêu diệt dữ liệu của công ty đến từ các nguồn nội bộ (đây là lý do rất nguy hiểm khi có nhiều nhân viên bất mãn) tất cả các gian lận. Tuy nhiên, hầu hết các lập trình viên dường như nghĩ rằng họ chỉ phải bảo vệ chống lại các mối đe dọa bên ngoài.

Tất nhiên bạn vẫn sẽ có một vài người có thể thực hiện các thay đổi trái phép, bạn không thể ngăn quản trị viên hệ thống thực hiện việc này. Nhưng với việc kiểm tra ít nhất bạn có thể giới hạn khả năng gây thiệt hại dữ liệu (và đặc biệt cẩn thận khi thuê dbas và cho phép không có quyền quản trị khác trên máy chủ cơ sở dữ liệu của bạn).

2

Các cột này vì lợi ích của DBA và nhà phát triển cơ sở dữ liệu. Họ chỉ cung cấp một cơ chế nhanh chóng để trả lời các câu hỏi như "Lần thay đổi cuối cùng này đã thay đổi khi nào?" "Ai đã thay đổi nó?" Chúng không đủ mạnh hoặc đủ hạt mịn để thỏa mãn việc tuân thủ SOX, HIPAA hoặc bất kỳ thứ gì.

Chỉ đơn giản là dễ dàng hơn để có các cột này trên mỗi bảng. Tất cả dữ liệu có thể thay đổi, vì vậy rất hữu ích khi biết khi nào các thay đổi xảy ra, đặc biệt nếu dữ liệu đó không được phép thay đổi. Có thể tự động hóa quy trình thêm chúng bằng cách sử dụng từ điển dữ liệu để tạo tập lệnh.

Thực hành tốt để các cột này được điền độc lập với ứng dụng, bằng trình kích hoạt hoặc một số cơ chế tương tự. Các cột này là siêu dữ liệu, ứng dụng không thực sự nhận thức được chúng.

Dựa vào đường mòn kiểm tra toàn diện để cung cấp chức năng này thường không phải là một tùy chọn. Dữ liệu kiểm toán được thu thập cho mục đích tuân thủ thường có quyền truy cập bị hạn chế và thực sự có thể được lưu trữ ở một vị trí thực tế riêng biệt.

0

Tôi tình cờ gặp vấn đề này, vì cùng một câu hỏi xuất hiện trong đầu tôi sáng nay. Mỗi câu trả lời đều có điểm và tôi chắc chắn đồng ý với tất cả các bạn. Không thể phủ nhận dữ liệu kinh doanh và dữ liệu giao dịch. Thay vào đó, tác giả cảm thấy nghi ngờ về các trường kiểm toán đối với một số cấu hình hoặc dữ liệu tĩnh.

Loại dữ liệu cấu hình này không thể cập nhật được bởi người dùng. Thông thường, chúng cũng có thể được đặt ở những nơi khác, chẳng hạn như các thuộc tính, tệp cấu hình hoặc thậm chí các hằng số được mã hóa cứng. Tất nhiên việc đặt dữ liệu cấu hình ở những nơi này có thể là kiểu dáng hay phong cách xấu, nhưng từ quan điểm của kiểm toán, chúng có quan trọng không? Ngoài ra, nếu những dữ liệu này có thể cập nhật bởi người dùng, thì những người duy nhất có thể cập nhật dữ liệu đó là dba hoặc tin tặc. Dba hoặc tin tặc độc hại thực sự sẽ biết luật trước khi họ vi phạm pháp luật và họ tìm cách phá vỡ luật pháp.

Đối với tôi, câu hỏi có liên quan nhiều hơn đến môi trường trong công ty của bạn. Công ty của bạn có văn hóa theo dõi mọi thông tin nhỏ bé không? Công ty của bạn có liên tục thực thi kỷ luật, giám sát hoặc kiểm toán nghiêm ngặt không? Việc có các trường kiểm toán này cho dữ liệu không phải của người dùng chỉ đơn giản là sự hài lòng của họ, nhiều hơn bất kỳ mục đích nào khác.

Các vấn đề liên quan