Tôi có nên cập nhật rõ ràng CẬP NHẬT vào các cột không nên cập nhật không?

Tôi đã quen làm việc trong các môi trường rất an toàn và vì vậy tôi thiết kế các quyền của mình ở mức độ chi tiết rất tốt. Một điều mà tôi thường làm là DENYngười dùng rõ ràng khả năng UPDATEcác cột không bao giờ được cập nhật.

Ví dụ:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

Hai cột này không bao giờ được thay đổi khi giá trị đã được đặt. Vì vậy, tôi sẽ dứt khoát DENYcác UPDATEphép trên chúng.

Gần đây, trong một cuộc họp nhóm, một nhà phát triển đã đưa ra quan điểm rằng logic để đảm bảo các trường không bao giờ được cập nhật phải được chứa trong lớp ứng dụng và không phải là lớp cơ sở dữ liệu trong trường hợp "họ cần cập nhật các giá trị vì một số lý do". Đối với tôi nghe có vẻ như tâm lý dev điển hình (tôi biết, tôi đã từng là một!)

Tôi là kiến ​​trúc sư cao cấp tại công ty của tôi và tôi luôn làm việc theo nguyên tắc ít nhất là các đặc quyền cần thiết để ứng dụng hoạt động. Tất cả các quyền được kiểm toán thường xuyên.

Thực hành tốt nhất trong kịch bản này là gì?

Đối số không có ý nghĩa. Tôi luôn muốn các điều khiển và các ràng buộc càng gần với dữ liệu càng tốt. Đặt nó trong lớp ứng dụng có nghĩa là nó chỉ ảnh hưởng đến những người sử dụng lớp ứng dụng và cũng giả định rằng mã sẽ không có lỗi và bảo mật xung quanh các đường dẫn mã đó sẽ có khả năng chống đạn. Đó là những giả định lớn.

Nếu chúng thực sự cần được cập nhật, thì điều đó có thể được thực hiện bởi một người không bị ảnh hưởng bởi điều rõ ràng DENY, hoặc người đó có thể tạm thời chuyển sang vai trò không bị ảnh hưởng hoặc DENYcó thể tạm thời bị xóa. Đây là những điều dễ dàng đối với bạn, như DBA, để thiết lập kiểm toán xung quanh. Trong ứng dụng? Không nhiều lắm.

Tôi hoàn toàn đồng ý với @Aaron về khía cạnh kỹ thuật này.

Ngoài ra tôi sẽ nói, liên quan đến thực tiễn tốt nhất:

1. Cho rằng đó là công việc / trách nhiệm của DBA trong việc bảo vệ dữ liệu, cách tiếp cận mặc định nên làm như vậy, vì DBA thấy phù hợp và yêu cầu một trường hợp kinh doanh vững chắc để thực hiện thay đổi. Một giả thuyết-tương lai-tiềm năng-hơi-có thể-được-nhất định-điều kiện-điều-đó-sẽ-bị-động-não-sau-sau-và-xác nhận-tốt-sau-đó-nhưng-có thể thay đổi-sau-hoặc-có thể không bao giờ lý do thực tế xảy ra (nghĩa là "vì một lý do nào đó") có vẻ hơi thiếu lý do biện minh, đặc biệt là khi chủ đề đang thay đổi một tiêu chuẩn / thực tiễn của công ty.

2. Không bao giờ tin tưởng ai đó muốn thực hiện thay đổi đối với một thứ không bao giờ thay đổi ;-), (thậm chí nhiều hơn nếu họ thậm chí không biết tại sao họ muốn).

3. Nói với nhà phát triển rằng họ được hoan nghênh thêm logic như vậy vào mã ứng dụng để ngăn những cập nhật đó. Nhưng, cũng là bạn sẽ không loại bỏ DENY. Nếu / khi ngày bao giờ đến (và nócó thể khôngcó lẽ sẽ không) rằng ai đó gặp lỗi khi cố cập nhật một trong các cột này, sau đó bạn có thể thảo luận về việc bạn có xóa hay không DENY, điều này sẽ yêu cầu sự biện minh thực tế, vững chắc về lý do tại sao ai đó sẽ cập nhật giá trị đó trong địa điểm đầu tiên.

   Quan điểm: cần có một trường hợp kinh doanh thực sự thúc đẩy những gì mọi người dành thời gian của họ vào. Thời gian là nhu cầu cao nhưng nguồn cung ngắn, vì vậy bạn (và mọi người khác) có nhiều việc quan trọng hơn là thay đổi hệ thống dựa trên ý kiến ​​của ai đó. Sẽ luôn có nhiều ý kiến ​​khác nhau (khoảng trắng so với tab, có ai không?) Và bạn có thể mất nhiều năm để thay đổi điều này nếu nhà phát triển đó rời đi và được thay thế bởi một người phản đối mạnh mẽ những trường đó có thể cập nhật. Nếu không có khách hàng nào yêu cầu điều này (hoặc một cái gì đó yêu cầu) và không có lợi ích hữu hình (thậm chí lợi ích bị trì hoãn như xóa nợ kỹ thuật, khó có thể hiển thị ROI, nhưng rất đáng giá trong khi cho rằng cơ hội của thời gian đó không dẫn đến tiết kiệm chi phí thực tế trong dài hạn là không có gì), sau đó đóng yêu cầu hoặc đặt nó ở mức tồn đọng ở mức ưu tiên thấp, ngay cả trong trường hợp chủ nghĩa duy tâm nói rằng nó nên được thay đổi (đây không phải là một trong những trường hợp đó, nhưng được đề cập cho những người cho rằng đó là). Chủ nghĩa lý tưởng là tuyệt vời cho các cuộc trò chuyện, nhưng các công ty không thể trả tiền thuê nhà, tiện ích, nhân viên, thuế, vv với lý tưởng.

4. @ jpmc26 là chính xác về nhu cầu giao tiếp, nhưng không chính xác về những gì cần truyền đạt. Có, bạn nên lắng nghe những gì người khác đang yêu cầu và tìm cách hiểu lý lẽ của họ, bao gồm đặt câu hỏi nếu bạn không rõ ràng về bất cứ điều gì.

   TUY NHIÊN, cơ sở dữ liệu không phụ thuộc vào ứng dụng và các chuyên gia cơ sở dữ liệu (quản trị viên, kỹ sư, bất kỳ tên nào công ty bạn sử dụng) không phụ thuộc vào nhà phát triển (dường như được ngụ ý trong câu trả lời đó). Bạn không làm việc cho các nhà phát triển, bạn làm việc cho công ty, giống như họ làm. Đây là một nỗ lực của nhóm và bạn không nên cầu xin sự tha thứ khi thực hiện công việc của mình. Điều đó nói rằng, các loại máy tính của chúng tôi không (thường) được biết đến với các kỹ năng giao tiếp giữa người với người, vì vậy, bạn thực sự cần đảm bảo rằng những người khác hiểu bạn , lý do của bạn là gì, trách nhiệm của bạn là gì, và công cụ này thực sự hoạt động như thế nào .

   Tôi đặt phần cuối cùng đó bởi vì có một mức độ hiểu lầm cao, thông tin sai lệch và thiếu kiến ​​thức ngoài kia (thậm chí một số ngay tại đây trên chính trang này). Ví dụ, dường như có khái niệm rằng tất cả các quy tắc là quy tắc kinh doanh. Chúng tôi cần giải thích rằng có một sự khác biệt giữa quy tắc dữ liệu và quy tắc kinh doanh (@Aaron gọi đây là "ràng buộc quy trình làm việc và ràng buộc dữ liệu" trong một nhận xét về câu hỏi) và trong khi hầu hết dữ liệu thuộc về ứng dụng, một số dữ liệu tự nhiên thuộc về ứng dụng, một số dữ liệu thực sự thuộc về mô hình dữ liệu. DBA có nên ra lệnh cho các nhà phát triển cách dữ liệu ứng dụng sẽ bị hạn chế không? Tất nhiên là không. Công việc của chúng tôi là cung cấp dữ liệu ứng dụng có thể như thế nàobị gò bó. Nếu việc vi phạm quy tắc kinh doanh liên quan đến dữ liệu ứng dụng có thể gây hại và ứng dụng không phải là cách duy nhất 100% để thao túng dữ liệu, thì có lẽ ràng buộc kiểm tra có thể thực sự hữu ích (và chúng không khó thay đổi hoặc xóa ).

   NHƯNG, đến từ hướng khác, các nhà phát triển không nên đưa ra cách xử lý dữ liệu mô hình dữ liệu (tức là dữ liệu meta). Điều này bao gồm các trường kiểm toán (chẳng hạn như created_on/ created_bycột) và cột PK / FK (các giá trị này chỉ được cho là được biết trong nội bộ và không được cung cấp cho khách hàng). Dữ liệu này không phải là những gì ứng dụng lưu trữ về khách hàng (ngay cả khi ứng dụng có thể nhìn thấy các giá trị và thậm chí sử dụng chúng, chẳng hạn như với ID), đó là những gì mô hình dữ liệu lưu trữ về dữ liệu của ứng dụng.

   Vì vậy, nó có ý nghĩa để sử dụng các quy tắc dữ liệu để bảo vệ dữ liệu mô hình dữ liệu. Và làm như vậy không có nghĩa là bạn sắp bắt đầu thêm các ràng buộc hoặc hạn chế đối với dữ liệu ứng dụng. NHƯNG, sẽ rất khó để chuyển cuộc trò chuyện về phía trước một cách thực sự hiệu quả nếu không hiểu được sự khác biệt này.

Vì thế:

1. Có, tôi thích ý tưởng rõ ràng DENYtrên các cột kiểm toán và cũng đã đề xuất tương tự ở những nơi tôi đã làm việc trong quá khứ.

2. Thông thường, tôi đã có một cuộc trò chuyện rất giống với một nhà phát triển chính (một người rất giỏi), có thể vào năm 2000, khi tôi bắt đầu thêm khóa ngoại. Ông lập luận (khá nghiêm túc) rằng đó là chủ nghĩa lý tưởng / lý tưởng quá mức không cần thiết (đại loại như thế, đã 17 năm kể từ cuộc trò chuyện đó) và không đáng để thực hiện. Ông đã khá rõ ràng rằng việc dọn dẹp dữ liệu liên quan nên được xử lý trong lớp ứng dụng. (vâng, tôi đã thêm FK vì anh ấy sẽ không phải là người dọn dẹp dữ liệu mồ côi mà mã của anh ấy chắc chắn sẽ tạo ra)

   Nhiều năm sau, ông xin lỗi vì đã đưa ra lập luận đó ;-)

Đây có lẽ là một vấn đề XY. Nhà phát triển có lẽ không đặc biệt quan tâm đến việc chặn các bản cập nhật cho một trường thực sự không đổi như thế nào created_on. Ví dụ cụ thể này là một hạn chế cực kỳ khiêm tốn.

Nhà phát triển có thể lo ngại rằng nhóm DBA (bao gồm cả bạn) có ý định thêm rất nhiều hoặc hạn chế phức tạp đến mức nó bắt đầu cản trở khả năng làm việc hiệu quả của họ hoặc khi có điều gì đó khác thường phát sinh hoặc có gì đó thay đổi, nhóm DBA sẽ chống lại những thay đổi và cản trở khả năng tiến bộ của nhóm nhà phát triển. Đây là một mối quan tâm tương đối hợp lý. Quan liêu và mất khả năng ảnh hưởng đến những thay đổi cần thiết là sự thật và việc mã hóa quá nhiều hoặc các ràng buộc phức tạp có thể có tác động tiêu cực đến hiệu suất và khả năng đáp ứng các thay đổi trong yêu cầu.

Nhà phát triển thậm chí có thể không nhận ra rằng đây là bản chất của mối quan tâm của họ. Họ có thể đã quen với việc cai trị cơ sở dữ liệu miễn phí và việc từ bỏ mức độ tự do đó là khó khăn, đặc biệt nếu bạn biết rằng bạn chưa bao giờ lạm dụng nó. Vì vậy, cảm giác lo lắng của họ về việc mất khả năng làm những gì họ cần cũng có thể mơ hồ và không rõ ràng.

Vì vậy, có một vài điều bạn nên làm để làm dịu những nỗi sợ hãi này:

1. Giao tiếp nhiều với các nhà phát triển. Đảm bảo bạn hiểu nhu cầu của các tính năng mà họ đang cố gắng xây dựng và đảm bảo rằng bạn sẽ phản hồi khi có thay đổi. Lắng nghe những gì họ nói, và làm việc chăm chỉ để tìm ra giải pháp cân bằng mối quan tâm của họ với bạn. Hãy sẵn sàng uốn cong khi họ có nhu cầu chính đáng. Hãy chắc chắn rằng họ biết bạn là đồng minh trong việc xây dựng phần mềm.
2. Hãy thận trọng về việc đưa vào các hạn chế. Các hạn chế, ngay cả những hạn chế nhằm cung cấp tính toàn vẹn và bảo mật, có thể khiến việc thích ứng với thay đổi hoặc xử lý các tình huống không lường trước trở nên khó khăn hơn. Vì vậy, hãy hiểu rằng mỗi hạn chế bạn thêm vào có khả năng có chi phí liên quan đến nó vì nó có khả năng tiết kiệm chi phí (ngoại trừ có thể có khóa chính và khóa ngoại, hầu như không có nhược điểm). Hãy tự tin rằng những hạn chế bạn áp đặt là thực sự cần thiết hoặc có lợi.
3. Tôi không thấy bất kỳ dấu hiệu nào bạn đang làm điều này, nhưng tôi muốn đề cập đến nó cho bất kỳ độc giả nào khác: không xem dữ liệu hoặc cơ sở dữ liệu là trách nhiệm của bạn hoặc nhóm của bạn. Dữ liệu là một tài sản cho toàn bộ công ty. Không có hệ thống để lưu trữ nó (cơ sở dữ liệu) và các tập lệnh, công cụ hoặc ứng dụng để tạo, cập nhật và tìm nạp nó, dữ liệu sẽ không có giá trị. Bởi vì mọi người đều phải sử dụng tài sản này, dữ liệu là trách nhiệm của mọi người. Cơ sở dữ liệu chỉ là một phần của việc nhận giá trị từ dữ liệu.

Bạn có những tuyên bố mâu thuẫn

• Các cột không bao giờ được cập nhật
• Họ cần cập nhật các giá trị vì một số lý do

Có thực sự tùy thuộc vào bạn để ra lệnh đầu tiên?

Bạn ném vào đặc quyền tối thiểu để ứng dụng hoạt động mà không cần bằng chứng ứng dụng sẽ không bao giờ cần cập nhật giá trị.

Ai chịu trách nhiệm về tính toàn vẹn dữ liệu?

Với các ràng buộc SQL, bạn có thể đảm bảo tính toàn vẹn dữ liệu? Không, bạn không thể vì thường có các quy tắc kinh doanh vượt xa những gì cơ sở dữ liệu có thể làm.

VendorID không bao giờ nên thay đổi nhưng nếu hai nhà cung cấp hợp nhất. Không bao giờ nói không bao giờ.

Nếu nhóm ứng dụng làm ô nhiễm dữ liệu và họ nói rằng họ cần quyền đó thì đó là quyền của họ. Nếu các nhóm ứng dụng làm việc cho bạn thì bạn có thể ra lệnh.

Câu hỏi thích hợp là ứng dụng có nên cập nhật dữ liệu không.