Mỗi câu lệnh SQL phải được xem xét bởi một DBA - chung?


11

Ý tôi là tất cả mọi thứ, không chỉ thay đổi lược đồ. Ngay cả một CHỌN đơn giản trên khóa chính cũng không thể đi vào sản xuất, mặc dù nó đã được các nhà phát triển khác xem xét mã (theo ngữ cảnh), mà không có đánh giá DBA về mọi tuyên bố, được trích xuất từ ​​mã và gửi với đầu ra EXPLAIN, chi tiết tần suất nó sẽ được gọi, v.v.

Nếu bạn đã ở trong một môi trường như vậy, bạn có thấy đó là một lợi ích ròng hay là một lực cản cho sự phát triển? Là một người đã làm việc với các cơ sở dữ liệu quan hệ trong nhiều năm, tôi thấy thái độ "các nhà phát triển không thể tin tưởng để sử dụng cơ sở dữ liệu" là không chính đáng, và tôi tò mò về mức độ phổ biến của tình huống này. Đối với những gì nó có giá trị, đây chỉ là để phát triển web, không phải là một cái gì đó quan trọng.


2
Chà, chúng tôi không đưa các câu lệnh SQL vào mã. Tuy nhiên, TẤT CẢ mã cần được xem xét bởi các cá nhân có kiến ​​thức phù hợp.
CaffGeek

4
Phát triển web là rất quan trọng. Kết quả là trực tiếp đối mặt với khách hàng (ai là vua của bạn) và thường xuyên hơn là không, dữ liệu nhạy cảm có thể truy cập được vào máy chủ web.
thiton

2
Câu hỏi là, nếu không phải mọi truy vấn đều được DBA chuyển qua, làm thế nào để bạn xác định những gì nên và không nên được DBA thông qua?
lập trình viên

6
@thiton: Đó là một tuyên bố trùm đầu giả định rằng TẤT CẢ các ứng dụng web đều hướng tới khách hàng công cộng và là ứng dụng quan trọng nhất trong tổ chức. Điều đó đơn giản là không đúng sự thật. Đôi khi các ứng dụng web là thứ ba hoặc thấp hơn (so với các ứng dụng khác). Một số chỉ được sử dụng bởi một nhóm nhỏ, nội bộ. Không biết @ DanEllis đang làm việc trên cái gì, chúng tôi thực sự không biết mức độ quan trọng của việc phát triển web này.
Thất vọngWithFormsDesigner

2
Bạn chưa bị cắn chưa? Cân nhắc hỏi về lý do tại sao quy trình này được thực hiện ...

Câu trả lời:


15

Tại một trong những công việc trước đây của tôi, tôi (cùng với ba lập trình viên khác) chịu trách nhiệm xem xét mọi thủ tục được lưu trữ được tạo hoặc cập nhật trước khi nó đi vào sản xuất cho khoảng hơn 40 lập trình viên. Là một nhà phê bình, đó là một trở ngại thực sự đối với thời gian của tôi nhưng nhìn chung nó vẫn cần thiết bởi vì cùng với đó, nhiều nhà phát triển sẽ phạm sai lầm một lần. Nó xuất hiện bởi vì chúng tôi đã có các lập trình viên ngoài khơi, những người đã viết các câu lệnh SQL thực sự tồi (hiệu quả khôn ngoan) và họ đã từ chối học (nhóm đó cuối cùng đã bị đóng cửa).

Nhìn chung, chúng tôi đã tìm kiếm:

  • Sử dụng chỉ mục - là truy vấn thực hiện quét toàn bộ bảng?
  • Khả năng bảo trì - là truy vấn sẽ cần phải được thay đổi trong một vài tuần bởi vì một cái gì đó đã được mã hóa cứng vào nó? Và truy vấn có đọc được không?
  • Hiệu quả tổng thể - một sự tham gia bên trong có thể được thay thế bằng một tồn tại? Sẽ thêm một trợ giúp với khối?
  • Sự cố khóa - truy vấn sẽ khóa cơ sở dữ liệu và ngăn cập nhật xảy ra? Điều này xảy ra nhiều hơn tôi quan tâm để suy nghĩ.

Thường xuyên hơn không phải hầu hết các truy vấn không có vấn đề và chúng tôi đã tiếp tục. Nhưng mỗi đánh giá mất từ ​​10 phút đến hai giờ tùy thuộc vào truy vấn. Một phần trong tôi thích ý tưởng thực hiện đánh giá vì nó ngăn cuộc gọi điện thoại 2 giờ sáng đáng sợ vì một số báo cáo đã gây ra sự cố với ứng dụng khác. Nhưng đồng thời tôi nghĩ rằng nó hơi quá mức vì tất cả chúng ta đều đã trưởng thành và người viết truy vấn nên tự làm tất cả những thứ đó.

Tôi nghĩ các truy vấn phức tạp nên là một phần của đánh giá mã tiêu chuẩn, nhưng không cần thông qua DBA. Cũng không cần xem lại các câu lệnh chèn / cập nhật / xóa đơn giản. Ngoài ra, là một người viết một truy vấn, bạn nên biết khi nào nó trở nên quá phức tạp và biết khi nào nên yêu cầu đánh giá từ một DBA.

Cập nhật Trong công việc đầu tiên của tôi, tất cả các truy vấn được viết bởi các DBA và đó là một kẻ giết thời gian lớn trong phát triển. Tôi đã phải gửi tất cả các cột tôi muốn, các bảng nơi các cột được đặt và cuối cùng là tiêu chí tìm kiếm của tôi. Ngay cả các câu lệnh chèn / cập nhật / xóa cơ bản cần thiết để đi qua một DBA. Cuối cùng, tôi đã đến điểm mà tôi có thể viết SQL mà tôi muốn, để họ xem xét nó và thực hiện bất kỳ thay đổi cần thiết nào, và sau đó bọc một thủ tục được lưu trữ xung quanh nó, nhưng điều đó chỉ có một vài năm ở đó. Công ty đặc biệt đó đã thuê rất nhiều sinh viên tốt nghiệp đại học gần đây và đây là cách họ đảm bảo những người mới không viết các truy vấn giết chết hiệu suất.


-1 Một câu trả lời tuyệt vời nhưng thật không may, câu hỏi là về đánh giá của một dba sau khi đánh giá lập trình viên đồng nghiệp. Câu trả lời này thực sự cho câu hỏi "tất cả các mã có nên được xem xét không" nhưng đó không phải là câu hỏi được hỏi. Tôi không đánh giá thấp hoặc bất chấp, chỉ khi họ trả lời không phải là câu trả lời cho câu hỏi.
Michael Durrant

Chính xác. Đây là mã đã được xem xét trong bối cảnh . Đó là quan trọng. Một truy vấn trong sự cô lập có thể trông vô hại, nhưng đặt nó trong một vòng lặp và đột nhiên nó ít như vậy.
Isvara

1
Có công cụ nào để tự động hóa loại điều này không? Tôi đang nghĩ về một công cụ tạo ra một kế hoạch thực hiện cho tất cả các truy vấn đã gửi và sau đó gắn cờ mọi thứ với quét toàn bộ bảng hoặc sản phẩm của Cartesian. Tôi nghi ngờ nó có thể nắm bắt mọi thứ , nhưng nó có thể sẽ tăng tốc thời gian xem xét và nó cũng có thể được các nhà phát triển chạy thông qua một tập lệnh, hoặc thậm chí tốt hơn nếu chạy tự động vào thời gian đăng ký mã.
Thất vọngWithFormsDesigner

10

Nó hoàn toàn phụ thuộc vào môi trường, ngành công nghiệp và công ty.

Vài ví dụ:

  • Tại NASA, nhiều cấp độ kiểm tra và đánh giá là tiêu chuẩn. "Đáng lẽ phải kiểm tra hai lần" nổi tiếng nhất là khi một tàu thăm dò được gửi tới Sao Hỏa và Hoa Kỳ đã tính toán bằng chân, nhưng người châu Âu tính bằng mét. Các thăm dò đã bị mất.

  • Tại một startup không có DBA (phổ biến hiện nay) sẽ không có đánh giá DBA và thậm chí có thể không có đánh giá lập trình viên (ví dụ: nếu không có lập trình viên nào khác trong công ty).

  • Tại một công ty có sản phẩm là kho dữ liệu gồm hàng trăm triệu hàng, đảm bảo rằng các truy vấn có hiệu quả và chính xác có thể là vấn đề chính của cốt lõi của doanh nghiệp cần được kiểm tra.

Một công ty có sản phẩm chính là một trang web tĩnh chủ yếu với một số lượng nhỏ các tương tác cơ sở dữ liệu, có thể coi cơ sở dữ liệu và hiệu quả của nó là ít liên quan. Có thể là công ty chọn chi tiêu "ngân sách" cho các trang tĩnh được coi là quan trọng nhất.


5

Tôi chưa bao giờ làm việc trong một môi trường như vậy, tôi chắc chắn tôi sẽ ghét nó. Một ý nghĩ xuất hiện trong đầu để bắt đầu theo dõi một số số liệu xung quanh ...

  • Một nhà phát triển dành bao nhiêu thời gian để rút sql ra khỏi mã và chuẩn bị gửi nó đến một DBA
  • DBA mất bao lâu để xem xét sql?
  • Bao lâu thì các thay đổi được yêu cầu bởi DBA? Chia nhỏ theo
    loại truy vấn ?

Theo dõi điều này trong một thời gian ngắn có thể sẽ cho thấy mức độ kéo của nó so với hiệu quả của nó.


6
Đây là những điều tuyệt vời để đo lường. Trong khi bạn đang ở đó, mất bao nhiêu thời gian để sửa mã bị hỏng được phép sản xuất? Mất bao nhiêu giờ để Bán hàng và Tiếp thị tìm kiếm khách hàng để thay thế những khách hàng bị mất trong khi trang web của bạn không hoạt động vì một mệnh đề WHERE bị bỏ lỡ gây ra quét bảng lặp đi lặp lại? Đánh giá mã có chi phí và lợi ích, đừng bỏ qua.

4
Đó là lý do tại sao điều quan trọng là phải biết DBA yêu cầu / cần bao nhiêu lần thay đổi. Câu hỏi nói rõ ràng rằng mọi thứ đều được xem xét, không có ngoại lệ. Đây là loại chính sách rộng thường có nhiều chi phí hơn lợi ích. Tôi là một người ủng hộ lớn cho việc xem xét và kiểm tra mã nhưng điều đó không có nghĩa là mọi dòng đều được xem xét hoặc kiểm tra. Chúng tôi được cho là chuyên gia và có sự khác biệt giữa kiểm soát chất lượng và em bé ngồi.
BZink

4

Hầu hết các nhà phát triển đều không biết gì khi nói đến cơ sở dữ liệu. Họ thậm chí không nhận thức được sự thiếu hiểu biết của họ. Tôi đã từng là một nhà phát triển không biết gì về bản thân mình.

Các nhà phát triển sống trong một thế giới tối ưu hóa là xấu xa. Tư duy đó không hoạt động khi bạn đang thực hiện các thao tác đối với đĩa. Tâm trí đó không hoạt động khi bạn chọn một kiểu dữ liệu lớn hơn 8 lần so với nó khiến cho chỉ số này lớn hơn 8 lần so với nó phải không còn phù hợp với bộ nhớ. Lối suy nghĩ đó không hoạt động khi bạn lập trình dựa trên API chung cập nhật dự phòng tất cả các cột trong một bảng (không cảm ơn các hạt đậu Java).

Họ không biết quét toàn bộ bảng là gì. Họ không biết cách xử lý dữ liệu trong một thao tác tập thay vì mở con trỏ. Tệ hơn là một con trỏ họ sẽ truy vấn dữ liệu, sau đó xử lý từng hàng một, nó sẽ quay trở lại cơ sở dữ liệu khi một bản cập nhật đơn giản đơn giản sẽ đủ. Kết quả trong hiệu suất HORRIBLE.

Họ không biết tác động nghiêm trọng của báo cáo đối với các bảng lớn. Có thể nhu cầu báo cáo sẽ yêu cầu tạo một lược đồ sao và nguồn cấp dữ liệu vào đó. Nhà phát triển trung bình của bạn sẽ chỉ truy vấn các bảng exisitng và tự hỏi tại sao phải mất 3 giờ để truy vấn chạy (đây là một con số thực).

Kiến thức mà nhà phát triển trung bình của bạn có sẽ đủ cho các ứng dụng CRUD "trung bình" trong đó người dùng chỉ cần chỉnh sửa bản ghi. Nó sẽ không đủ khi họ thoát ra khỏi bong bóng Ruby-on-Crack và bước vào thế giới thực.


Bạn có muốn nghe âm thanh nào hơn thánh không?
Sevenseacat

2
@Karpie, ít nhất (các) anh ấy đã dành thời gian để trả lời rút ra từ kinh nghiệm của bản thân, thay vì đưa ra một nhận xét vô bổ, châm biếm về câu trả lời của người khác như Karpie đã làm.
vẽ

2

Phụ thuộc vào mức độ lớn của cơ sở dữ liệu và nếu nó được chia sẻ giữa nhiều ứng dụng. Thông thường, nhóm DBA thích biết những truy vấn nào sẽ được chạy để họ có thể đảm bảo rằng các chỉ mục thích hợp được đặt đúng chỗ hoặc để họ biết ai sẽ thông báo nếu họ phải phân vùng bảng. Và họ có xu hướng tốt hơn một chút so với nhà phát triển trung bình khi đọc các kế hoạch thực hiện truy vấn và phát hiện ra các địa điểm nơi các gợi ý có thể được chỉ định để cải thiện hiệu suất. Đây cũng là cơ hội để họ nhận được thông báo rằng một số truy vấn có tác động cao sẽ xuất hiện trong phiên bản tiếp theo, vì vậy họ có thể thu thập các số liệu thống kê khác nhau cho trình tối ưu hóa.


2

Tôi đã không làm việc trong một môi trường như vậy, tôi cũng không

Có một sự khác biệt giữa tinh thần đồng đội và quan liêu thù địch. Là một nhà phát triển, tôi rất muốn có đầu vào DBA cho các truy vấn khó. Nhưng tôi biết khi nào cần giúp đỡ.

Nếu tôi không đủ năng lực cho SELECTcác truy vấn đơn giản , tôi sẽ bị sa thải.


1
Mặc dù đó là một quan điểm hợp lý, bạn phải cho phép rằng chúng ta rất ít người trong chúng ta khá thông minh như chúng ta muốn nghĩ rằng chúng ta là những kẻ phạm tội tồi tệ nhất là những người thiếu hiểu biết nhất (gần như theo định nghĩa không phải là những điều đó) vấn đề là bằng cách có một quy tắc chăn - mọi người đều đối xử bình đẳng
Murph

2
@Murph - hoàn toàn. Tôi có thể phạm sai lầm. Nhưng tôi cũng có thể nghỉ 2 giờ mỗi ngày. Mọi người nên theo dõi thời gian phòng tắm của họ để ngăn chặn điều đó? Chúng ta có nên ký vào các biểu mẫu để lấy kẹp giấy để tránh bị mất cắp giấy không? Tại một số điểm, bạn phải tin tưởng mọi người hoặc sa thải họ. Truy vấn chậm của tôi có một chi phí, nhưng quá trình xem xét hút linh hồn, tốn thời gian cũng vậy. Chỉ khi sự khác biệt hiệu suất cơ sở dữ liệu nhỏ sẽ có giá hàng triệu (hoặc cuộc sống) thì tôi mới chấp nhận loại điều này.
Nathan Long

1
Vấn đề với điều này là bạn có thể không phải là nhà phát triển trung bình; và rất có thể không phải là nhà phát triển vấn đề. Tôi đã làm việc ở một nơi như thế này, và thật là may mắn; nhưng bạn biết gì không? Các DBA của chúng tôi là những người nhận được cuộc gọi vào lúc nửa đêm khi các truy vấn bị phá vỡ, không phải tôi. Nếu họ là những người chịu trách nhiệm, họ có quyền xem lại mã mà họ chịu trách nhiệm.
Telastyn

@Telastyn - "nhà phát triển không trung bình" tôi không mua; Tôi vẫn nói đừng thuê những nhà phát triển tồi. Nhưng vâng, nếu các DBA phải nhận cuộc gọi, tôi thông cảm thêm một chút.
Nathan Long

@NathanLong về bối cảnh của nó - trong bối cảnh mà bạn làm việc có lẽ không phải là vấn đề, ở những người khác rõ ràng nó có tiềm năng và một trong những cách bạn tránh được một số vấn đề là bằng cách có những quy tắc dường như vô nghĩa (mặc dù , giống như thực tế là tôi luôn sử dụng {} trong các câu lệnh if của mình, nó được thực hiện cho một mục đích). Thật tệ "bởi vì tôi không thích nó và tôi nghĩ rằng tôi an toàn nên nó không nên áp dụng cho tôi" là một lập luận đáng ngờ (logic tương tự được áp dụng để bỏ qua các giới hạn tốc độ). Hmm, đó là tranh luận) -: Xin lỗi.
Murph

2

Tôi đã thấy điều này được thực hiện ở một vài nơi khác nhau. Đó là lý thuyết tuyệt vời, nhưng tôi hiếm khi thấy nó có hiệu quả. Đây là lý do tại sao. Đầu tiên, nếu bạn có một nhóm các DBA (hoặc những người khác), tôi thường thấy rằng người ít năng lực nhất hoặc ít thích nhất trong nhóm sẽ nhận được nhiều công việc đánh giá. Tại sao bạn nói? Đó là bởi vì, không ai khác muốn làm điều đó, và những người khác đang bận rộn làm những việc khác có lẽ khẩn cấp hơn. Đã bao giờ nhìn thấy một DBA ngồi xung quanh và nói, "Đàn ông mọi thứ đang chạy hoàn hảo; tôi chỉ có thể ngồi lại và lướt mạng. Tôi ước mình có việc để làm." Tôi cũng vậy, ít nhất không phải là những người tốt. Họ bận rộn hoặc bận rộn hơn những người khác. Điều này có nghĩa là người có khả năng thấp nhất có khả năng thực hiện đánh giá và đây chính xác là người bạn không muốn làm việc đó. Mã bạn muốn xem xét là mã thực sự rất khó mà mọi người nhìn vào và chuyển nó đi như một loại ma thuật đen. Các DBA cơ sở hoặc chỉ là những người xấu đơn thuần, sẽ không bao giờ có thể nắm bắt được sự tinh tế trong cách một truy vấn thực sự khó hoạt động. Hiếm khi, như không bao giờ, có ai từng nói, "Người đàn ông tôi đã không nghĩ đến việc chọn một hàng duy nhất trên bàn bằng khóa chính! Cảm ơn DBA bạn là người cứu cánh." Vì vậy, trong kịch bản này, thực sự tất cả những gì bạn đang làm là tạo ra rất nhiều công việc với giá trị nhỏ. Hãy nghĩ đến việc chọn một hàng duy nhất trong bảng bằng khóa chính! Cảm ơn DBA, bạn là người cứu cánh. "Vì vậy, trong kịch bản này, thực sự tất cả những gì bạn đang làm là tạo ra rất nhiều công việc với giá trị nhỏ. Hãy nghĩ đến việc chọn một hàng duy nhất trong bảng bằng khóa chính! Cảm ơn DBA, bạn là người cứu cánh. "Vì vậy, trong kịch bản này, thực sự tất cả những gì bạn đang làm là tạo ra rất nhiều công việc với giá trị nhỏ.

Thứ hai, nó chỉ đơn giản là làm việc nhiều hơn cho nhóm DB. Điều có lẽ sẽ xảy ra ngay cả khi họ nhìn vào những thứ khác là họ sẽ xem xét nhanh về nó và một cái gì đó sẽ bị bỏ lỡ. Họ là những người bận rộn và việc xem lại mã thực sự tốn thời gian. Trong thực tế, thật không công bằng khi họ được giao nhiệm vụ này, bởi vì đó là lý do để mọi người khác lười biếng và sử dụng chúng như một lối thoát, cuối cùng là những gì xảy ra. Một cái gì đó phá vỡ trong sản xuất, và nhà phát triển nhanh chóng chỉ ra, "Vâng DBA đã xem xét nó." Bây giờ điều này đúng mọi lúc, không, nhưng nó là một phần của thời gian và thường là từ những người cần phải có mã của họ thực sự được xem xét. Vì vậy, bạn đã chôn DBA với công việc làm thêm và buộc người đó phải chịu trách nhiệm cho những sai lầm của người khác, khi người đó có thể không '

Cách duy nhất để thực sự giải quyết vấn đề là có những người biết cách viết mã SQL viết nó. Thỉnh thoảng họ có nên nhận đầu vào từ các DBA không? Tất nhiên họ nên, nhưng tôi đã luôn luôn thấy, nếu bạn không có thời gian để làm điều đó ngay lần đầu tiên, khi nào bạn sẽ tìm thấy thời gian để sửa nó.


2

Tôi đã làm việc trong môi trường đó. Tất cả các thay đổi hệ thống được đánh giá ngang hàng bởi các đồng nghiệp thích hợp. Đối với tôi điều đó chỉ có nghĩa là tôi phải lên kế hoạch trước và gửi những thay đổi của mình trước vài ngày. SQL đã đến các DBA, những người cuối cùng sẽ phát hành SQL vào sản xuất.

SQL của tôi thường ổn, họ bắt gặp một vài lỗi ngớ ngẩn. Lúc đầu tôi cảm thấy quá quan liêu, nhưng tôi làm về tài chính. Bạn đã thấy những gì xảy ra (Nếu bạn ở Anh) vài tháng trước khi một ngân hàng lớn ở đây làm rối tung việc nâng cấp thường xuyên và làm rối tung tất cả các giao dịch dẫn đến hàng triệu (Ít nhất hàng trăm nghìn) người không thể nhận được bằng tiền của họ.


0

Tôi thậm chí sẽ đi xa hơn. Tôi sẽ kiểm tra mã xung quanh và xem các biến được chuyển đến truy vấn như thế nào. Thông thường để xem các nhà phát triển đưa ứng dụng của họ vào các cuộc tấn công tiêm sql do thiếu kiến ​​thức cơ bản ("điều này không thể bị hack" các giả định sai).

Ngoài ra, các nhà phát triển chưa có kinh nghiệm có thể kéo cơ sở dữ liệu xuống đầu gối với việc sử dụng sai ORM hoặc truy vấn không tối ưu.

Trong dự án gần đây nhất mà tôi làm việc, không có nhà phát triển front-end nào được phép truy cập cơ sở dữ liệu trực tiếp. Họ đưa ra yêu cầu về một hàm trả về một tập hợp dữ liệu nhất định và các nhà phát triển back-end chuẩn bị nó cho họ. Nó hoạt động khá tốt, các nhà phát triển front-end viết UI và xử lý dữ liệu được cung cấp bởi các chức năng được viết bởi các nhà phát triển back-end.


0

Trong nhóm phát triển của chúng tôi, có một nhóm nhỏ gồm 4 Nhà phát triển cơ sở dữ liệu có kinh nghiệm trong nền tảng DBMS mà chúng tôi sử dụng. Họ viết tất cả SQL hoặc ít nhất là đánh giá và thực hiện các thay đổi để đáp ứng các tiêu chuẩn mã hóa của họ bất kỳ SQL nào được viết bởi các nhà phát triển .Net. Họ là một phần của nhóm dự án. Các DBA sản xuất thuộc về một bộ phận hoàn toàn khác và công việc của họ là hoạt động. Họ không xem lại mã SQL hoặc lược đồ của chúng tôi và thậm chí việc triển khai được viết theo kịch bản, tất cả những gì họ làm là chạy tập lệnh. Hầu hết họ giúp đỡ là trong điều chỉnh hiệu suất.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.