Giả sử chúng ta đang sử dụng java hoặc python để truy cập cơ sở dữ liệu. Sau đó, nó được coi là lãng phí thời gian và không cần thiết để tìm hiểu các loại cấu trúc dữ liệu và các đối tượng đang được sử dụng trong sql?

Hãy trả lời trong tài liệu tham khảo cho ngành công nghiệp phần mềm. Hãy cố gắng nói trong trường hợp nào sẽ tốt để có kiến ​​thức về những điều đó.

Tôi đã tranh luận với ai đó rằng không cần thiết phải học những thứ như vậy.

Vài năm trước tôi đã làm việc trên một ứng dụng được viết bởi một người rõ ràng chưa bao giờ biết cách hoạt động của cơ sở dữ liệu SQL. Tôi đã được cung cấp một báo cáo sự cố để khắc phục - trang tóm tắt trạng thái chính, vốn luôn chậm, giờ đã bắt đầu chậm đến mức nó đã hết thời gian thực thi tập lệnh máy chủ (trong 3 phút) trong khi kết xuất. Có vẻ như khi số lượng khách hàng trong hệ thống đang tăng lên, thời gian để hiển thị trang trạng thái đang tăng theo phương pháp bậc hai .

Tôi không mất nhiều thời gian để nhận ra vấn đề, đó là trang đã sử dụng truy vấn hợp nhất dữ liệu từ hai bảng khác nhau, không có bảng nào có bất kỳ chỉ số nào . Vì mỗi bảng có kích thước tăng theo O (n) với số lượng máy khách, nên truy vấn mất thời gian O (n ^ 2) để thực thi vì nó đang tìm nạp từng hàng của bảng đầu tiên và cho mỗi hàng đó đã lấy từng hàng của bảng thứ hai để so sánh chúng.

Việc giải quyết vấn đề mất vài phút và bất cứ ai hiểu cách thức hoạt động của cơ sở dữ liệu SQL sẽ có thể làm điều đó nhanh chóng . Các tác giả ban đầu đã không, vì vậy để lại một giải pháp hoàn toàn không đầy đủ.

Bạn cần hiểu làm thế nào (ít nhất là về mặt nói chung) một công nghệ hoạt động để tránh mắc phải những sai lầm khủng khiếp như thế này.

Đừng giảm khả năng bạn thực sự cần phải vào cơ sở dữ liệu và truy vấn trực tiếp vào cơ sở dữ liệu như là một phần của quy trình gỡ lỗi. Nếu bạn đã từng làm điều đó, chắc chắn bạn sẽ muốn biết tất cả về công nghệ cơ sở dữ liệu và cơ sở dữ liệu cụ thể của bạn được cấu trúc như thế nào. Có lẽ nó sẽ không xảy ra. Nhưng nếu có (và theo kinh nghiệm của tôi thì nó luôn luôn có lúc) bạn sẽ cần kiến ​​thức đó.

Nhưng hãy giả sử rằng bạn sẽ không bao giờ cần phải tìm kiếm trực tiếp trong cơ sở dữ liệu vì bất kỳ lý do nào. Hãy nói rằng bạn đang sử dụng ORM theo cách phù hợp với tất cả các hoạt động tốt nhất do cộng đồng đưa ra. Bạn có thể tạo một ứng dụng biểu diễn mà không có bất kỳ sai lầm / tắc nghẽn / thiếu hiệu quả nào xảy ra với dữ liệu. Nhưng nếu bạn không thực sự hiểu cơ sở dữ liệu cơ bản, bạn sẽ không thực sự hiểu lý do tại sao bạn làm mọi thứ theo cách của bạn. Tệ hơn, bạn không thực sựhiểu cách thực hành tốt nhất áp dụng cho trường hợp sử dụng cụ thể của bạn. Những sự thật này sẽ gây ra một số nghi ngờ rằng bạn đang tạo ra giải pháp tối ưu. Giải pháp của bạn có thể hiệu quả, nhưng bạn sẽ không thể nói "đây là giải pháp tốt nhất" với bất kỳ sự tự tin thực sự nào. Nếu bạn không thể nói điều đó, bạn không phải là một tài sản lớn trong mắt công ty của bạn và nếu bạn nói điều đó và bạn đã sai, điều đó sẽ trông thật tồi tệ đối với bạn.

Không chỉ là những hangout triết học mà tôi có về việc không học các nguyên tắc cơ bản của ngăn xếp công nghệ của bạn, tôi giải quyết các lý do hữu hình để biết ngăn xếp của bạn từ trên xuống dưới hàng ngày. Trong công ty của tôi, chúng tôi có một khối nguyên khối khổng lồ xử lý lượng dữ liệu khổng lồ. Mọi thứ được mô hình hóa tốt, nhưng có hàng tá trên hàng chục loại đối tượng trong ứng dụng và các mối quan hệ giữa chúng là một mạng lưới tuyệt vời của các khóa ngoại và bảng liên kết. Thành thật mà nói, nếu bạn không bao giờ tìm kiếm SQL và chỉ đi sâu vào ứng dụng (mặc dù mọi thứ được mô hình hóa chính xác trong ứng dụng và sử dụng ORM và thiết lập các thực tiễn tốt nhất cho ORM đó), hãy tìm ra cách lấy bit thông tin này cho bit khác ở đây có thể là một việc vặt gần như không thể. Nhưng nếu bạn có thể đi sâu vào DB, bạn có thể thấy tất cả các trường trong mỗi mô hình, theo các kết nối giữa các bảng, tìm ra một đường dẫn từ mảnh này sang mảnh khác, kiểm tra nó bằng một truy vấn, sau đó đi tìm các mô hình thích hợp để thực hiện nó thông qua ORM một cách nhanh chóng và hiệu quả. Tôi sẽ không là một nửa tài sản cho công ty của mình nếu tôi không có mức độ thoải mái cao với SQL kim loại trần.

Chỉ đến một điểm

Là một nhà phát triển phần mềm, có lẽ bạn sẽ phải truy vấn và cập nhật cơ sở dữ liệu và biết cách DB hoạt động là rất quan trọng để tránh các truy vấn xấu, tham gia không hiệu quả, v.v. Bạn có thể có một DBA chuyên dụng, người có thể quyết định nơi thêm chỉ mục vào phân vùng cơ sở dữ liệu, nhưng bạn không thể tin vào nó, không phải trong các công ty nhỏ và không phải lúc nào cũng ở các công ty lớn.

Tuy nhiên

Mặc dù bạn nên biết các chỉ mục là gì và chúng nên được sử dụng như thế nào, nhưng bạn không cần biết chúng hoạt động như thế nào trong nội bộ. Các chi tiết thực hiện nội bộ chỉ là - chi tiết thực hiện.

Biết cách kiểm tra kế hoạch truy vấn SQL và xây dựng mã của bạn theo đó là một phần của API mà DB của bạn hiển thị. Biết các thuật toán nội bộ và cấu trúc dữ liệu mà nó sử dụng để đạt được nó? Không phải. Rất nhiều. Tương tự như vậy, tôi nên biết ý nghĩa hiệu suất của việc lưu tệp vào đĩa. Tôi không cần quan tâm đến cách hệ thống tập tin của tôi được thực hiện.

Tuy nhiên đến Tuy nhiên

Nếu, như làm rõ các bình luận cho thấy, câu hỏi là về việc hiểu quyền truy cập DB so với việc hoàn toàn dựa vào ORM và các tóm tắt mã khác, thì câu trả lời là "có, bạn nên biết truy cập DB". Không phải mọi dự án đều sử dụng hoặc có thể sử dụng ORM và ORM không lý tưởng cho một số tác vụ nhất định (báo cáo, chèn hàng loạt và hơn thế nữa).

Nó hoàn toàn xứng đáng với thời gian! Trở thành một nhà phát triển ngăn xếp đầy đủ cho phép bạn tạo ra các giải pháp giá trị gia tăng một cách hiệu quả. Tôi đã thấy tất cả các sự cố truyền thông và phát triển silo quá thường xuyên ... Tăng gấp ba lần thời gian phát triển và một nửa chất lượng.

Vào cuối ngày, bạn càng có nhiều kỹ năng, bạn sẽ càng có giá trị.

Nếu bạn tuyên bố không biết gì về xe hơi , liệu tôi có vui khi bạn phục vụ phanh của tôi không? Tôi nghĩ là không.

Cơ sở dữ liệu khác biệt đáng kể so với cấu trúc dữ liệu mà bạn đã từng làm việc với lập trình. Chúng có những điểm kỳ lạ và đặc trưng riêng và những thứ khác sẽ cắn bạn trong Hiệu suất Ứng dụng nếu bạn không nắm bắt được chúng.

Tôi đã gặp những người có tâm lý "Tôi không cần biết Cơ sở dữ liệu"; hầu hết trong số họ coi Cơ sở dữ liệu là không có gì nhiều hơn Bảng tính và tạo ra các ứng dụng hoạt động kém hiệu quả.

Điều đó nói rằng, bạn không cần phải biết cơ sở dữ liệu hoạt động như thế nào trong nội bộ .

Làm quen với những thứ hợp lý; Bảng, Chỉ mục, Lượt xem và những thứ tương tự.

Đừng để bị cuốn vào các chi tiết triển khai về cách một DBMS cụ thể xử lý những điều này; tất cả họ làm điều đó khác với nhau (và đôi khi giữa các phiên bản của chính họ !), vì vậy một "tổng quan" chung sẽ phục vụ bạn tốt nhất.

Bạn hoàn toàn cần biết. Ví dụ: nếu cơ sở dữ liệu của bạn đang lưu trữ ngày, bạn cần biết loại chính xác nào bạn có thể mong đợi. Nếu bạn đang lưu trữ dấu thời gian trong một DATEtrường, bạn nên biết liệu cơ sở dữ liệu sẽ cắt bớt giá trị của bạn đến giây gần nhất (hoặc tệ hơn, vào ngày gần nhất). Bạn cũng nên biết rằng các giá trị đến từ một NUMBER(9,2)cột phải được lưu trữ trong biến dấu phẩy động, trong khi các giá trị trong một cột có NUMBER(15,0)thể được lưu trữ dưới dạng số nguyên. Bạn cũng có thể thấy thuận tiện khi biết những điều kỳ lạ nhỏ như CHARcác cột của Oracle được đệm trống theo chiều dài được chỉ định, trong khi VARCHAR2các cột thì không. Và LONGkiểu dữ liệu của họ thực sự lưu trữ các chuỗi có độ dài thay đổi, không phải số.

Mọi cơ sở dữ liệu đều có những điểm kỳ quặc và bạn nên biết chúng là gì (hoặc ít nhất là những gì cần tìm).

Hiểu cách mọi thứ hoạt động dưới mui xe sẽ giúp bạn gỡ lỗi các truy vấn của bạn để xem xét hiệu suất và lưu trữ.

Ví dụ: một truy vấn phạm vi sẽ hoạt động tốt hơn với loại chỉ mục cây B. Và khi thực hiện tham gia, bạn có thể thêm gợi ý vào công cụ truy vấn về việc nên sử dụng tham gia HASH hoặc MERGE. Và về mặt vật lý, bạn có thể phân phối các bảng trong một cơ sở dữ liệu đến các phân vùng đĩa vật lý khác nhau để giảm thiểu sự tranh chấp đầu (có thể vẫn phù hợp ngay cả với SSD).

Trước tiên, bạn cần phải rõ ràng về SQL là gì và không. SQL là ngôn ngữ truy vấn và ngôn ngữ thao tác dữ liệu được sử dụng để truy cập và thao tác dữ liệu trong cơ sở dữ liệu quan hệ. Nhưng các đối tượng lược đồ và dữ liệu (bảng, cột, chỉ mục, ràng buộc) trong cơ sở dữ liệu không phải là "trong SQL", SQL chỉ là một ngôn ngữ có thể để truy vấn và thao tác dữ liệu.

Để có thể làm việc hiệu quả với cơ sở dữ liệu quan hệ, bạn cần hiểu các bảng, cột, kiểu dữ liệu, khóa chính, khóa ngoài và chỉ mục. Bạn cũng cần hiểu những điều cơ bản của truy vấn: phép chiếu, bộ lọc, phép nối. Bạn cần hiểu những điều cơ bản của chuẩn hóa.

Nhưng về nguyên tắc, không có điều nào trong số này yêu cầu bạn chạm vào SQL. Bạn có thể thiết kế lược đồ cơ sở dữ liệu trong trình thiết kế GUI và bạn có thể viết các truy vấn và cập nhật bằng một số ngôn ngữ khác như SqlAlchemy cho Python hoặc Linq cho .net. Một số thậm chí cho rằng các ngôn ngữ này là một đại diện thuần túy hơn của mô hình quan hệ so với SQL.

Vì vậy, về mặt lý thuyết, bạn của bạn đã đúng - bạn không cần phải học SQL. Nhưng bạn vẫn cần học cách cơ sở dữ liệu quan hệ hoạt động và khi bạn biết điều đó, SQL khá dễ học, vì nó chỉ là một số cú pháp.

Mặc dù không cần thiết, nhưng khá thuận tiện khi biết SQL, vì bạn có thể truy vấn bất kỳ cơ sở dữ liệu trực tiếp nào trong SQL mà không cần một lớp dịch riêng. Và vì tất cả các hướng dẫn, sách và ví dụ đều sử dụng SQL, nên sẽ khó tránh khỏi việc học nó.

Tôi gặp phải một vấn đề trong đó các số sê-ri đang được lưu trữ dưới dạng số thập phân 10 chữ số trong cơ sở dữ liệu và đọc thành số nguyên 32 bit trong Java. Điều này vẫn ổn cho đến khi chúng tôi đạt được số sê-ri đầu tiên lớn hơn 2G, vì vậy nó không thể được biểu thị bằng số nguyên có chữ ký 32 bit của Java. Hiểu các kiểu dữ liệu DB có thể đã ngăn chặn vấn đề này.