Ở mức độ nào thì Quản trị viên Cơ sở dữ liệu cần biết các ngôn ngữ lập trình cấp hệ thống hoặc ứng dụng (ví dụ .NET hoặc PHP) bên cạnh "chỉ SQL"?
Đối với mục đích của câu hỏi này, không có phiên bản cụ thể nào của tiêu chuẩn SQL được xem xét cho câu trả lời này (SQL ANSI 86, SQL ISO 87, SQL: 2008) vì câu hỏi liên quan đến ngôn ngữ máy tính để bàn hoặc máy chủ bên ngoài lĩnh vực SQL.
Câu trả lời:
Nó phụ thuộc.
Trong một cửa hàng lớn, có thể không phải vì bạn có 1000 máy chủ để chăm sóc và các công cụ của bạn được cung cấp. Trong một cửa hàng nhỏ, có lẽ bạn sẽ cần nhiều kiến thức hơn vì bạn có một khoản tiền gửi rộng hơn.
Các ngôn ngữ tập lệnh (ví dụ như PowerShell, cmd.exe) luôn hữu ích để theo dõi, triển khai, v.v. Tôi thường có một số tập lệnh Perl mà tôi phải duy trì (chỉ khoảng). Sau đó, có các gói ETL các loại mà bạn sẽ biết.
Nói rằng, hầu hết các DBA (mà tôi biết) sẽ có thể viết các công cụ CLR cơ bản hoặc biết rõ PL / SQL. Đối với tôi, đường phân chia là biết về các mẫu hoặc kiến trúc rộng hơn của .net hoặc Java. Tôi không cần nó như một nhà phát triển DB hoặc DBA. Theo cùng một cách mà .net hoặc PHP hoặc Java Monkeys không hiểu thiết kế cơ sở dữ liệu hoặc kiến trúc hoặc mã cũng như tôi làm.
Cá nhân, tôi quyết định ngừng theo đuổi ngôn ngữ khách hàng mới nhất hoặc tốt nhất nhiều năm trước và tập trung vào công việc cơ sở dữ liệu. Điều đó không làm cho tôi trở thành một "người không lập trình": Tôi cần phải học lại nếu tôi phải.
Tôi đã biết các DBA thoát khỏi ít hoặc không có kỹ năng lập trình, nhưng mọi DBA tôi từng coi là tốt đều có kỹ năng lập trình hợp lý ít nhất. Một hoặc hai tôi có thể nghĩ rằng có nền tảng phát triển đáng kể và là những nhà phát triển khá giỏi theo cách riêng của họ. Có một công bằng số lượng của mã nguồn mở công cụ được viết bởi những người làm việc như DBA trong công việc ngày của họ và IIRC chàng người đã viết cóc sử dụng để làm việc như một DBA.
Tùy thuộc vào vai trò, bạn có thể thấy mình viết hoặc điều chỉnh truy vấn, viết tập lệnh để tự động hóa các tác vụ hoặc tư vấn về thiết kế ứng dụng. Trong một số trường hợp, bạn có thể chỉ cần chú ý đến một loạt các máy chủ thông qua OEM hoặc một số công cụ giám sát khác.
Các môi trường phát triển 'doanh nghiệp' hiện đại như .Net hoặc Java đủ phức tạp để nhà phát triển có thể tạo ra sự nghiệp chỉ chuyên về chúng. Là một DBA, đặc biệt là trong không gian phát triển, có kiến thức làm việc về C # hoặc Java có thể không bị tổn thương, nhưng có lẽ bạn sẽ không dành nhiều thời gian để thực sự mã hóa chúng.
Bạn có thể sẽ nhận được nhiều dặm hơn từ bất kỳ công cụ kịch bản nào được sử dụng trên nền tảng của bạn, mặc dù rất nhiều hệ thống phơi bày API .Net, Java, COM hoặc API dịch vụ web. Nếu bạn cần mã hóa một cái gì đó chống lại các API này, bạn sẽ cần ít nhất một kiến thức làm việc cơ bản về thứ gì đó có thể tiêu thụ API đó. Tuy nhiên, các kỹ năng kiến trúc ứng dụng nâng cao thường không cần thiết để làm điều này.
Một số nhà phát triển sẽ có các kỹ năng cơ sở dữ liệu mạnh mẽ, nhưng nỗi sợ phi lý về cơ sở dữ liệu là khá phổ biến trong giới phát triển. Nhiều nhà phát triển cũng không bao giờ thực sự hiểu được mô hình 'thiết lập các hoạt động' làm nền tảng cho SQL. Là một Dev DBA, bạn có thể thấy mình phải giải quyết hậu quả của việc này và có thể phải can thiệp vào mã thủ tục được lưu trữ để sắp xếp các vấn đề về hiệu suất.
ETL và công cụ xung quanh cơ sở dữ liệu cũng có thể rơi vào tình trạng của DBA. Tôi đã thấy khá nhiều vai trò DBA được quảng cáo dường như liên quan đến một lượng đáng kể công việc phát triển back-end. Điều này sẽ phổ biến nhất trong các công ty nhỏ hơn. Một người đăng gần đây muốn tích hợp các số liệu tùy chỉnh vào Trình quản lý doanh nghiệp của Oracle, có API plugin để thực hiện việc này. Nó là khá phổ biến để xem các yêu cầu như bật lên này, và về cơ bản cách duy nhất để làm điều này là viết một số mã keo.
Có rất nhiều 'Công cụ' làm việc trong CNTT và họ có thể hoàn thành công việc hữu ích bất chấp chủ nghĩa địa phương. Tuy nhiên, khi các công cụ hết hơi, thường thì cách duy nhất để hoàn thành công việc là thực sự viết một chút mã để thực hiện. Đây là nơi kỹ năng lập trình tách đàn ông khỏi các chàng trai.
Tôi sẽ nói không điển hình, nhưng nó không bao giờ đau. SQL Server đủ lớn để tôi không nghĩ một người có thể làm chủ toàn bộ sản phẩm. Tôi đã là một DBA kể từ SQL Server 4.2 và tự coi mình là một chuyên gia trong hầu hết các lĩnh vực, nhưng tôi thừa nhận tôi sẽ không thể viết một truy vấn MDX mà không cần google trong tầm tay mỗi bước.
Điều tôi đang cố gắng nói là bạn không thể là một chuyên gia về mọi thứ. Trở thành một DBA thực sự tốt có nghĩa là bạn phải giỏi T-SQL, nhưng không có khả năng rất tốt về .NET, hoặc ít nhất là không hiệu quả như những người khác có thể tập trung thời gian vào .NET.
Powershell là điều tốt để biết, cũng như SSIS. Ngoài ra, để lại các ngôn ngữ phát triển khác cho các nhà phát triển.
Đó là kinh nghiệm của tôi rằng trong khi hầu hết các DBA có nền tảng phát triển nào đó, họ hoàn toàn không cần phải viết mã. Các DBA thực sự tốt mà tôi đã làm việc cùng đã có kiến thức sâu rộng về nhiều chủ đề bao gồm kịch bản shell, hệ điều hành và kiến thức ứng dụng chuyên ngành (ví dụ: PeopleSoft).
Tôi đã có một người hướng dẫn Quản trị Cơ sở dữ liệu ở trường học, người đã cho chúng tôi một danh sách các câu hỏi mà bất kỳ DBA tốt (Oracle) nào cũng có thể trả lời: (Tôi sẽ chỉ đăng một số điểm nổi bật từ danh sách 40 hoặc hơn)
(Oracle) DBA cần biết những điều này để có hiệu quả. Hầu hết các nhà phát triển mà tôi biết (người chống lại Oracle) sẽ khó có thể trả lời chính xác một hoặc hai trong số này.
Nếu bạn là DBA, có lẽ bạn đang làm việc trong lĩnh vực hiệu suất và bảo mật (trong số những người khác). Điều này có thể liên quan đến hồ sơ và hỗ trợ điều chỉnh các ứng dụng khách mà các nhà phát triển đang làm việc. Do đó, chắc chắn sẽ không đau khi biết những điều cơ bản về ngôn ngữ mà các nhà phát triển đang sử dụng và cách giao tiếp với máy chủ cơ sở dữ liệu. Đối với SQL Server, đó có lẽ là .NET. Đối với MySQL, có lẽ một số kết hợp của php hoặc java.
Ví dụ: nếu máy chủ bị áp lực đối với các luồng máy khách, thì nó có thể giúp thông báo cho các nhà phát triển rằng họ nên sử dụng các cá thể singleton cho ObjectDataSource để họ có thể sử dụng lại một kết nối cơ sở dữ liệu. Và cũng đảm bảo rằng họ đang sử dụng các truy vấn được tham số hóa đúng cách để hạn chế việc tiêm SQL. Những thứ như thế.
Bạn sẽ không thực hiện bất kỳ chương trình nào theo nghĩa là phát triển các ứng dụng khách nếu bạn hoàn toàn là một DBA, nhưng bạn nên biết chúng hoạt động như thế nào (nói chung).
Chà, xem nào, Oracle sử dụng PL / SQL rất giống với Pascal (ngôn ngữ từng được sử dụng để sản xuất mã ứng dụng trên máy tính để bàn nhưng đã thất bại trong những năm gần đây và các nhà phát triển đã chuyển sang Delphi, một số đã phát triển từ đó đến .NET) và Oracle hiện cũng hỗ trợ Java cho một số hoạt động. Vì một DBA của Oracle phải biết tất cả các khía cạnh của hệ thống để được đánh giá tốt, tôi sẽ nói rằng việc biết Pascal và Java sẽ là một yêu cầu.
TSQL có khả năng viết mã được quản lý .NET (CLR) cho một số chức năng trong Sql Server, và do đó, một DBA tốt có lẽ sẽ cần phải biết về điều này (nhưng không phải lúc nào cũng có thể được sử dụng trong các phiên bản cũ hơn, vì vậy rất nhiều các DBA có xu hướng né tránh tính năng đó theo kinh nghiệm của tôi).
Vì vậy, đó là hai người lớn, và những người mà hầu hết mọi người đề cập đến khi họ hỏi khi bạn hỏi. Tôi không biết tất cả các công cụ khác để biết những gì họ làm và không hỗ trợ, nhưng tôi biết rằng rất nhiều công cụ khác có tích hợp ngôn ngữ bên cạnh SQL.
Tôi khá tin rằng chỉ những cửa hàng lớn có ứng dụng lớn mới có nhu cầu về một DBA không lập trình, vì các cửa hàng nhỏ với cơ sở dữ liệu đơn giản mới có thể thoát khỏi nhà phát triển / DBA toàn năng. Để một DBA trở thành bậc thầy của một sản phẩm (Oracle, SQL Server, bất cứ điều gì) cần phải có nhu cầu về kiến thức này! DBA phải chịu những môi trường và vấn đề phức tạp để giúp anh ta trở nên hiểu biết hơn. Điều này về cơ bản là một cơn thịnh nộ của tôi, bởi vì tôi là một DBA tại một cửa hàng nhỏ và tôi không làm bất cứ điều gì đòi hỏi nhiều hơn 2 nơ-ron thần kinh, tôi nghĩ rằng tôi đang lãng phí thời gian của mình vào công việc này. Tôi muốn trở thành một nhà phát triển.