Lập trình viên có kinh nghiệm nên biết truy vấn cơ sở dữ liệu? [đóng cửa]

35

Có rất nhiều lập trình viên ngoài kia cũng là một chuyên gia về thiết kế cơ sở dữ liệu viết và truy vấn.

Đây có nên là một yêu cầu cốt lõi để trở thành một lập trình viên chuyên gia hoặc kỹ sư phần mềm?

Mặc dù có rất nhiều điểm tương đồng trong cách phát triển truy vấn và mã, nhưng ý kiến cá nhân của tôi là, Truy vấn dường như có Cấu trúc khác với Mã và có thể khó khăn để làm chủ cả hai do các cách tiếp cận khác nhau.

database query

— Shamim Hafiz
nguồn

2

"Cấu trúc" nghĩa là gì? Nếu bạn đang nói về ngữ nghĩa, hơn là nắm bắt bất kỳ loại ngữ nghĩa mới nào sẽ không là vấn đề đối với một " chuyên gia ". Theo định nghĩa. OTOH, chỉ có một vài nhà phát triển tiếp xúc với cơ sở dữ liệu và ngôn ngữ truy vấn, phần còn lại chúng tôi không quan tâm gì cả.

— SK-logic

3

Tôi nghĩ rằng đây là một giả định sai lầm: "Có rất nhiều lập trình viên ngoài kia cũng là một chuyên gia về viết truy vấn và thiết kế cơ sở dữ liệu." Có tương đối ít lập trình viên là chuyên gia về những điều này: DBA! = SE.

— Ashley

1

Làm thế nào là thực sự khó khăn để viết các truy vấn cơ sở dữ liệu?

— Thuyền trưởng Sensible

@CaptainShakespeare, thực sự nó có thể trở nên khá khó khăn khi bạn vượt qua các hoạt động CRUD. Ty làm báo cáo phức tạp đôi khi. Và sau đó nhìn vào các truy vấn điều chỉnh hiệu suất.

— HLGEM

69

Việc viết truy vấn cơ sở dữ liệu có nên là một yêu cầu cốt lõi hay không phụ thuộc vào công việc, nhưng cơ sở dữ liệu quan hệ có mặt khắp nơi trong công nghệ hiện tại.

Vì vậy, nếu tôi gặp một lập trình viên không biết cách viết các truy vấn cơ sở dữ liệu, tôi sẽ mong đợi một trong hai điều sau:

Họ thường thiếu kinh nghiệm.
Họ rất chuyên môn trong lĩnh vực khác (ví dụ như các hệ thống nhúng) và chưa bao giờ cần phải học nó.

Các truy vấn cơ sở dữ liệu khác về cơ bản với các ngôn ngữ lập trình chuẩn hơn. Chúng là đại số và dự định hoạt động trên dữ liệu quan hệ, trong khi C # hoặc Java là bắt buộc và hoạt động trên đĩa, bộ nhớ, đầu vào của người dùng, v.v. Ngay cả các ngôn ngữ chức năng như LISP hoặc Haskell có dạng đại số hơn ít hướng đến dữ liệu quan hệ.

EDIT: Như tôi và những người khác đã chỉ ra trong các bình luận, có một số lý do hợp lệ tại sao một nhà phát triển có kinh nghiệm có thể không biết rõ các truy vấn cơ sở dữ liệu:

Nhóm của họ đã sử dụng ORM / NoQuery
Nhóm của họ có lập trình viên DB
Sự phức tạp của ứng dụng là trong logic nghiệp vụ và các truy vấn DB là tầm thường
Nhóm của họ phân bổ công việc sao cho một số lập trình viên không viết truy vấn

Mặc dù hợp lệ, những cảnh báo này không phải là lý do thuyết phục tại sao một nhà phát triển có kinh nghiệm sẽ không biết các truy vấn cơ sở dữ liệu. Trừ khi chuyên môn cao, một lập trình viên nên làm quen với cơ sở dữ liệu quan hệ.

Tóm lại, hầu hết các nhà phát triển có kinh nghiệm nên biết các truy vấn cơ sở dữ liệu .

— Matthew Rodatus
nguồn

1

Vì vậy, nếu ai đó đã làm một dự án không tầm thường sử dụng Cơ sở dữ liệu, anh ta sẽ được làm quen với các truy vấn, phải không?

— Shamim Hafiz

3

@Shamim, tôi mong muốn người này có kinh nghiệm vừa phải với các truy vấn trừ khi người này là cấp cơ sở hoặc cấp mới vào nghề. Có lẽ người này chỉ có một vài năm kinh nghiệm và được bảo vệ trong một đội ngũ chuyên môn cao?

— maple_shaft

12

@Shamim có lẽ tôi sẽ mong như vậy. Họ vẫn có thể là một lập trình viên giỏi. Những câu hỏi như thế này rất khó trả lời, bởi vì chúng có quá nhiều cảnh báo: có thể nhóm đã có một lập trình viên DB; có lẽ tính không phải của ứng dụng là trong logic nghiệp vụ và các truy vấn cơ sở dữ liệu là tầm thường; có thể họ phân bổ công việc sao cho lập trình viên của bạn không làm việc với các truy vấn; v.v.

— Matthew Rodatus

4

Nhóm phát triển của tôi đã dành riêng các lập trình viên PL / SQL như một phần của dự án. Vì vậy, trong khi các lập trình viên .Net có thể thực hiện các truy vấn đơn giản, họ có mặt để xem xét nó và phát triển các truy vấn phức tạp hơn. Ngoài ra, với sự phổ biến của ORM (và NOSQL) tại sao bạn nghĩ các nhà phát triển không phải SQL phải biết các truy vấn phức tạp.

— softveda

2

@Matthew Rodatus: Tôi đã làm việc ở những nơi có thư viện quản lý truy vấn, vì vậy về mặt lý thuyết có thể làm việc ở đó mà không cần hiểu SQL đơn giản. Tôi tin rằng tất cả các nhà phát triển đều có năng lực trong thực tế.

— David Thornley

23

Bất kỳ kỹ sư phần mềm nào cũng cần có hiểu biết cơ bản về cơ sở dữ liệu và cách lưu trữ và truy xuất dữ liệu bằng SQL, ít nhất là đến mức họ hiểu được điều này có thể được sử dụng để làm gì (và tôi sẽ bao gồm hiểu biết về khóa, khung nhìn , thủ tục lưu trữ và kích hoạt).

Không phải mọi kỹ sư phần mềm đều cần phải là một chuyên gia và mức độ chuyên môn cần thiết thực sự phụ thuộc vào loại phần mềm họ tập trung vào. Phần mềm nhúng, trình điều khiển phần cứng và hệ điều hành hiếm khi sử dụng SQL, nhưng phần mềm ứng dụng (có thể là web hoặc máy tính để bàn hoặc dịch vụ / daemon) sử dụng cơ sở dữ liệu mọi lúc.

— sóigangsz
nguồn

1

May mắn thay, ngày nay việc làm các ứng dụng mà không cần bất kỳ RDBMS nào là hoàn toàn ổn. Hầu hết các nhiệm vụ không cần chúng, hoặc đơn giản là không thể ánh xạ đầy đủ đến một mô hình quan hệ. Có hàng tấn tùy chọn lưu trữ không liên quan có sẵn.

— SK-logic

8

Điều này tổng hợp ý kiến của tôi là tốt. Chuyên gia? Không có kiến thức? Vâng.

— Wayne Molina

2

@ SK-logic, Những loại tùy chọn nào bạn cảm thấy làm cho cơ sở dữ liệu quan hệ không liên quan? Kho dữ liệu quá chuyên biệt để phân tích trở nên hữu ích trong hệ thống giao dịch. Và đừng để tôi bắt đầu với mọi thứ sai với OODBMS.

— maple_shaft

1

@maple_shaft, có rất nhiều giải pháp lưu trữ hướng miền chuyên biệt. RDBMSes cố gắng chung chung và thất bại nặng nề trong đó. Trong một số trường hợp, ngay cả DBMS chữ tượng hình cổ đại cũng tốt hơn nhiều so với quan hệ.

— SK-logic

6

Không phải tất cả các phần mềm máy tính để bàn đều sử dụng cơ sở dữ liệu, vì vậy hãy cẩn thận khi bạn nói rằng điều đó xảy ra mọi lúc.

— Adam Lear

18

Có một số lĩnh vực chuyên môn (ví dụ hệ thống nhúng), nơi kiến thức cơ sở dữ liệu là không cần thiết. Nhưng hầu hết các ứng dụng kinh doanh đều sử dụng một cơ sở dữ liệu thuộc loại nào đó và nếu bạn không hiểu kỹ về cách sử dụng nó đúng cách, bạn có thể tạo ra một mớ hỗn độn hiệu năng cực kỳ khó khắc phục. Tái cấu trúc cơ sở dữ liệu có thể là một quá trình phức tạp và khó khăn và nhiều nơi lựa chọn không khắc phục các vấn đề cấu trúc vì khó khăn đó và chỉ đào sâu vào một lỗ hổng. Nếu bạn có kiến thức cơ sở dữ liệu, thiết kế sẽ dễ dàng hơn nhiều và có khả năng hoạt động tốt hơn theo thời gian.

ORM không phải là một thay thế để có được kiến thức cơ sở dữ liệu. Bất cứ ai sử dụng một mà không biết các kiến thức cơ bản về truy vấn và thiết kế cơ sở dữ liệu sẽ phải chịu một cơ sở dữ liệu được thiết kế kém, được thiết kế kém sẽ ảnh hưởng đến phạm vi dài của ứng dụng của bạn để xử lý tải. ORM trong tay một người biết mình đang làm gì là tốt; trong tay những người không thể bận tâm tìm hiểu về cơ sở dữ liệu, họ thường là một thảm họa.

Nếu tôi có một dự án với phần cuối cơ sở dữ liệu, chuyên gia cơ sở dữ liệu sẽ là nhà phát triển thứ hai tôi sẽ thuê (sau nhà phát triển ứng dụng nội bộ). Cơ sở dữ liệu nói chung không phải là cơ sở dữ liệu, dữ liệu đó vẫn sẽ ở đó gần giống với hình thức 20 năm sau, nó trả tiền để có chuyên môn trong giai đoạn đầu.

Các dự án thường gặp rắc rối vì họ không thuê những người này cho đến khi cơ sở dữ liệu có 100.000.000 hồ sơ và đang chạy chậm. Hoặc họ đổ lỗi cho công cụ là xấu (không có SQL Server nào không chậm nếu bạn thiết kế chính xác) không phải là sự bất tài trong thiết kế của họ.

— HLGEM
nguồn

4

+1 để đề cập rằng sự hiện diện của ORM không thay thế nhu cầu biết SQL (hoặc các yếu tố cơ bản trong bất kỳ loại db nào bạn đang sử dụng).

— RHSeeger

4

+1 và tôi ước tôi có thể cung cấp cho bạn thêm 100! Tôi biết rằng corname! = Quan hệ nhân quả nhưng đối với tôi rõ ràng hơn là các nhà phát triển ứng dụng hiệu quả nhất mà tôi đã làm việc với EVER có sự hiểu biết thấu đáo về cách viết một truy vấn CHỌN tiêu chuẩn. Tôi có thể trao cho nhà phát triển giỏi một mô hình dữ liệu và "câu hỏi" về dữ liệu và người đó cuối cùng sẽ có thể viết một truy vấn "trả lời" câu hỏi của tôi.

— maple_shaft

1

+1, hoàn toàn đồng ý. Tôi không mua lời giải thích rằng 'chúng tôi sử dụng ORM' hoặc 'chúng tôi có các lập trình viên chuyên dụng cho điều đó'. Nếu ai đó thực sự có kinh nghiệm , họ sẽ hoàn thành vai trò của nhà phát triển db tại một thời điểm. Đó là những gì kinh nghiệm.

— GrandmasterB

15

Câu trả lời đúng về mặt chính trị: Nó phụ thuộc. Kiến thức SQL không có giá trị gì nếu nhà phát triển không bao giờ làm việc với cơ sở dữ liệu quan hệ (và trong thời đại ứng dụng NoQuery ngày nay, điều đó thực sự rất có khả năng).

Thứ hai, khi có một DBA hoặc người viết truy vấn toàn thời gian (bất kể tiêu đề là gì), thì sự hiểu biết cũng có tầm quan trọng thấp hơn.

Điều đó chỉ thực sự quan trọng nếu nhà phát triển cần phải là người giao dịch và có yêu cầu trong các dự án của anh ta về việc sử dụng cơ sở dữ liệu quan hệ (ví dụ: trong các ứng dụng web lỗi thời hoặc kết nối với cơ sở dữ liệu hiện có)

Ý kiến cá nhân của tôi: Không. Một nhà phát triển phần mềm có kinh nghiệm sẽ có thể học một kỹ năng mới (như SQL) nếu và khi họ cần, không phải 'theo mặc định'. Tính linh hoạt và khả năng học hỏi và hiểu là, imho, điều gì làm nên sự khác biệt của một nhà phát triển giỏi so với một người ổn. Quy tắc 'búa vàng' cũng được áp dụng - nếu bạn có một nhà phát triển có kiến thức SQL rộng rãi, rất có thể nhà phát triển này sẽ rút ra công cụ mà anh ta biết rõ nhất - cơ sở dữ liệu quan hệ - để cố gắng giải quyết mọi vấn đề, trong khi nó không nhất thiết phải có để là giải pháp tốt nhất. Tất nhiên, điều này cũng áp dụng cho những người ủng hộ NoQuery ,;).

Chọn công cụ phù hợp cho công việc phù hợp là điều mà một lập trình viên có kinh nghiệm nên biết.

— Cthulhu
nguồn

Cơ sở dữ liệu NoQuery không xử lý nhiều dữ liệu hơn hoặc nhanh hơn cơ sở dữ liệu quan hệ. Tôi không biết nơi bạn nghe nói rằng, nhưng đó là cách trắng trợn, một cách nguy hiểm sai.

— Aaronaught

@Aaronaught - Đã chỉnh sửa, cảm ơn vì đã ủng hộ giả định sớm của tôi, :).

— Cthulhu

7

Kiểm tra phần giới thiệu wikipedia này về Lập trình máy tính:

Lập trình máy tính (thường được rút ngắn để lập trình hoặc mã hóa) là quá trình thiết kế, viết, kiểm tra, gỡ lỗi / xử lý sự cố và duy trì mã nguồn của các chương trình máy tính. Mã nguồn này được viết bằng ngôn ngữ lập trình. Mục đích của lập trình là tạo ra một chương trình thể hiện một hành vi mong muốn nhất định.

Các truy vấn cơ sở dữ liệu có ngôn ngữ riêng của chúng, chúng có thể được thiết kế, kiểm tra, gỡ lỗi và xử lý. Mục đích của truy vấn cơ sở dữ liệu là cho phép bạn có được thông tin bạn cần, theo cách bạn cần.

Vì vậy, tôi nghĩ rằng đó là lập trình, chắc chắn.

— guiman
nguồn

7

Một kỹ sư phần mềm giỏi có nền tảng về các ứng dụng doanh nghiệp và doanh nghiệp (EDIT: cụ thể trong các dự án sử dụng RDBMS) nên có kiến thức chuyên môn về viết các truy vấn cơ sở dữ liệu quan hệ theo định dạng chuẩn. Hơn nữa, họ có thể hiểu lược đồ phức tạp và đề xuất các thiết kế lược đồ có độ phức tạp ít nhất vừa phải.

Thiết kế lược đồ cực kỳ tiên tiến hoặc phức tạp phải là lĩnh vực của một người lập mô hình dữ liệu hoặc kiến trúc sư chức năng.

Điều này không có nghĩa là Lập trình viên Cơ sở dữ liệu cũng không có chỗ. Các thủ tục lưu trữ phức tạp, các truy vấn phức tạp và hiệu quả và thiết kế và kiến trúc phần mềm cơ sở dữ liệu tập trung vào các công cụ và dịch vụ duy nhất của một nhà cung cấp cơ sở dữ liệu duy nhất (Ví dụ: Oracle, MySQL, SQLServer, v.v.) nên dành cho phần mềm chuyên nghiệp các kỹ sư có kinh nghiệm với các cuộc tấn công chuyên môn cao và phức tạp này.

Tuy nhiên, phần lớn các hệ thống doanh nghiệp và doanh nghiệp theo quan điểm của tôi không chứng minh được sự cần thiết của các nhà lập mô hình dữ liệu và lập trình viên cơ sở dữ liệu chuyên ngành nhưng tôi đã làm việc với các dự án như vậy trước khi được hưởng lợi rất nhiều từ kiến thức và chuyên môn mà những người này mang đến.

— phong_shaft
nguồn

2

-1: hoàn toàn không đồng ý rằng một kỹ sư phần mềm "tốt" nên là một chuyên gia về các truy vấn cơ sở dữ liệu quan hệ.

— John Saunders

3

Bạn vẫn không đồng ý nếu tôi nói rằng một kỹ sư phần mềm ứng dụng ENTERPRISE hoặc KINH DOANH tốt (trái ngược với các hệ thống nhúng, v.v ...) và nếu tôi nói rằng người này nên là một chuyên gia về truy vấn cơ sở dữ liệu quan hệ STANDARD (không có nhà cung cấp quần ưa thích chi tiết cụ thể như truy vấn phân tích và tương tự)? Một sự hiểu biết thấu đáo về các câu lệnh SQL SELECT, tất cả các loại phép nối, liên kết, giao thoa và sáp nhập, các khung nhìn nội tuyến, các điều kiện, thứ tự và nhóm các kết quả nhóm nên được hiểu một cách kỹ lưỡng và được thể hiện bởi kỹ sư phần mềm mang nhãn mà tôi đã chỉ định ở trên.

— maple_shaft

4

Meh. Tôi làm việc tại một công ty phần mềm lớn và chúng tôi không đối phó với bất kỳ RDBMS nào. Công việc cuối cùng của tôi là phát triển phần mềm máy tính để bàn cũng không yêu cầu bất kỳ SQL nào. Tôi không chắc cách bạn xác định các ứng dụng doanh nghiệp và doanh nghiệp, nhưng dường như quan điểm của bạn về mọi thứ hơi hẹp.

— Adam Lear

2

Tôi đứng trước những gì tôi nói. Về mặt lý thuyết nếu ứng dụng được xếp tầng và thành phần tốt thì không cần thiết tuy nhiên trong toàn bộ kinh nghiệm chuyên môn của tôi, nhóm của tôi và tôi sẽ TRỞ LẠI nếu chúng tôi không phải là chuyên gia về SQL, ngay cả khi chúng tôi có một nhóm chuyên dụng về thiết kế và phát triển RDBMS. Có lẽ tôi lỗi thời hoặc chỉ gặp may mắn trong sự nghiệp?

— maple_shaft

3

@maple_shaft Vâng, không phải các ứng dụng tôi đã làm việc đã được cấu thành đủ. Đó là họ đã không sử dụng bất kỳ RDBMS, giai đoạn. Các lĩnh vực khác nhau, tôi đoán. Vấn đề là, bạn không thể nói rằng mọi nhà phát triển doanh nghiệp / doanh nghiệp phải giỏi SQL. Nó đơn giản là không đúng sự thật. Hãy giỏi về nó nếu bạn sử dụng nó. Đừng quá lo lắng nếu bạn không cần đến khi bạn cần nó, như với bất kỳ ngôn ngữ hoặc công nghệ nào khác.

— Adam Lear

6

Những người khác đã trả lời câu hỏi của bạn về các truy vấn cơ sở dữ liệu.

Thiết kế cơ sở dữ liệu là một loại thiết kế đặc biệt. Nó không khó để học, nhưng người thiết kế cơ sở dữ liệu điển hình không có nhiều cơ hội để thiết kế cơ sở dữ liệu.

Nơi tôi đang làm việc hiện có cùng một thiết kế cơ sở dữ liệu như năm 1970. Chúng tôi đã chuyển cơ sở dữ liệu từ IDMS sang DB2, nhưng đó là cùng một thiết kế cơ sở dữ liệu mạng. Tôi đã có cơ hội tạo 5 bảng DB2 mới trong 9 năm tôi đã làm việc ở đây.

Tôi nghi ngờ rằng có rất ít nơi làm việc với một nhà thiết kế cơ sở dữ liệu chuyên dụng. Vì vậy, tôi kết luận rằng thiết kế cơ sở dữ liệu được coi là một phần của tiết mục của một nhà phân tích cao cấp.

— Gilbert Le Blanc
nguồn

5

Tôi thực sự ngạc nhiên khi rất nhiều người trong chúng ta nghĩ rằng mọi sự phát triển đều xoay quanh một cơ sở dữ liệu và một cơ sở dữ liệu SQL ở đó.

Những người khác đã đề cập đến nhiều cách mà chúng ta có thể tránh được sự khó chịu của SQL trong công việc của mình, ngay cả khi chúng ta đang làm việc (gián tiếp) với cơ sở dữ liệu, nhưng tất cả các nhà phát triển viết phần sụn cho 101 sản phẩm điện của chúng ta sở hữu? Còn những kẻ chuyên theo dõi thời gian thực thì sao?

Tôi muốn đề xuất rằng phần lớn các nhà phát triển ngày nay sẽ có các kỹ năng SQL ở mức độ khác nhau, nhưng nó không phải là một phong vũ biểu về khả năng của họ.

— cjmUK
nguồn

5

Tôi nghĩ bạn đánh giá quá cao tầm quan trọng của cơ sở dữ liệu trong phần mềm.

Nhiều lớp ứng dụng không phải là trung tâm cơ sở dữ liệu.

Bây giờ chúng ta có cần một DBMS trong trình xử lý văn bản và trình chỉnh sửa hình ảnh không? Điều gì về nhận dạng giọng nói và hệ thống thị giác máy tính có chứa nhiều truy vấn cơ sở dữ liệu?

Và những gì của trình chỉnh sửa video tuyến tính và công cụ vật lý trò chơi video?

— Alex Jasmin
nguồn

5

Tôi mong muốn một nhà phát triển tổng quát có ít nhất nhận thức về các công nghệ cơ sở dữ liệu (quan hệ hoặc mặt khác) và có thể thảo luận về những ưu và nhược điểm của việc sử dụng chúng. Mặt khác, tôi sợ tất cả những gì họ biết làm là nhét dữ liệu vào các tệp phẳng.

— Barry Brown
nguồn

4

Tôi không nghĩ rằng viết truy vấn nên là một yêu cầu cốt lõi cho các lập trình viên. Phải nói rằng, tôi tin rằng một lập trình viên có thể viết các truy vấn và thiết kế cơ sở dữ liệu sẽ có giá trị hơn đối với một tổ chức.

Tuy nhiên, nếu lập trình viên này chỉ có thể viết các truy vấn loại "select * from tblxxxx" thì tôi sẽ không coi lập trình viên này là một chuyên gia. Tương tự như vậy, nếu cơ sở dữ liệu được thiết kế bởi lập trình viên này đặt các mối quan hệ một-nhiều vào một bảng thay vì hai bảng thì tôi sẽ không coi lập trình viên này là một chuyên gia.

Đây là cách tôi giải thích điều này với những người không làm CNTT. Các chuyên gia CNTT chuyên về một số lĩnh vực tương tự như cách thợ mộc, thợ điện và thợ ống nước chuyên về các lĩnh vực được tôn trọng. Họ có xu hướng chồng chéo một số kỹ năng nhưng không phải là chuyên gia trong tất cả các lĩnh vực. Một thợ điện có thể thực hiện các nhiệm vụ mộc đơn giản với sự tự tin nhưng sẽ không làm tốt việc cố gắng giải quyết các cấu trúc phức tạp.

Tương tự như vậy, một lập trình viên có thể và nên biết cách viết hoặc thao tác các truy vấn đơn giản và thiết kế cơ sở dữ liệu nhưng không được dự kiến sẽ thiết kế một cấu trúc dữ liệu phức tạp.

— Michael Riley - AKA Gunny
nguồn

3

Nhìn xung quanh trong bộ phận của chúng tôi, nó phụ thuộc:

Của chúng tôi phát triển máy tính để bàn / web / máy chủ . Ít nhất là cần thiết để viết các tuyên bố thô từ cơ bản đến nâng cao tùy thuộc vào chuyên môn của họ. Để tối ưu hóa, chúng tôi có một vài quản trị viên DB chuyên biệt.
Lập trình viên nhúng của chúng tôi . Khá nhiều người chưa bao giờ vượt qua "select * from mytable". Tuy nhiên, điều đó cũng thay đổi trong vài tháng qua với việc giới thiệu sqllite cho các dự án của họ.

— Carra
nguồn