Tại sao các tính năng cơ sở dữ liệu bị bỏ qua và thay vào đó được phát minh lại ở tầng giữa?

Những lý do hàng đầu ( ngoài "tính độc lập cơ sở dữ liệu" ) mà hầu hết các dự án CNTT ngày nay dường như bỏ qua sự phong phú của các tính năng tồn tại trong các công cụ cơ sở dữ liệu hiện đại như Oracle 11g và SQL Server 2008?

Hoặc, mượn từ blog Tuyên bố Helsinki, viết theo cách này:

Trong hai mươi năm qua, chúng tôi nhận thấy rằng chức năng (tính năng) có sẵn cho chúng tôi bên trong DBMS, đã phát triển theo cấp số nhân. Những tính năng này cho phép chúng tôi xây dựng các ứng dụng cơ sở dữ liệu. Đó là những gì tất cả chúng ta bắt đầu làm trong những năm 90 bùng nổ.

Nhưng rồi vào buổi bình minh của thiên niên kỷ mới, một điều gì đó đã xảy ra. Và điều gì đó bí ẩn đã làm cho vai trò của DBMS bên trong một dự án ứng dụng cơ sở dữ liệu giảm xuống không đáng kể. (...) Kể từ thiên niên kỷ mới, chúng tôi đang đẩy tất cả logic ứng dụng ra khỏi DBMS vào các máy chủ cấp trung bình. Chức năng của những thứ được triển khai bên ngoài DBMS đã bùng nổ và DBMS có nhiều tính năng hầu như không được sử dụng cho bất cứ thứ gì ngoài lưu trữ hàng.

Chúng ta đang nói về những thứ như

• Các quy trình đã lưu trữ được sử dụng làm API dữ liệu (để bảo mật và tránh lưu lượng mạng quá mức)
• Chế độ xem cụ thể hóa
• Thay vì kích hoạt
• Truy vấn phân cấp (kết nối bằng)
• Địa lý (kiểu dữ liệu không gian)
• Phân tích (khách hàng tiềm năng, độ trễ, tổng hợp, khối lập phương, v.v.)
• Cơ sở dữ liệu riêng ảo (VPD)
• Kiểm toán cấp cơ sở dữ liệu
• Truy vấn hồi tưởng
• Tạo XML và chuyển đổi XSL trong cơ sở dữ liệu
• Chú thích HTTP từ cơ sở dữ liệu
• Trình lập lịch công việc nền

Tại sao những tính năng này không được sử dụng? Tại sao hầu hết các nhà phát triển Java, .NET và PHP lại gắn bó với cách tiếp cận "CHỌN * TỪ mytable"?

Bởi vì các thủ tục được lưu trữ:

• thêm một ngôn ngữ phát triển khác, làm tăng độ phức tạp và mã có khả năng dư thừa (logic được viết bằng cả hai ngôn ngữ);
• thường có khả năng tạo công cụ, giám sát và gỡ lỗi kém hơn PHP, C #, Java, Python, v.v.;
• thường ít khả năng hơn hầu hết các ngôn ngữ bậc trung;
• chỉ có lợi thế khi chuyển đổi dữ liệu khối lượng lớn (nơi bạn tránh máy chủ quay vòng), có xu hướng chỉ sử dụng thực tế ở mức tối thiểu.

Điều đó đang được nói, đó là một phương pháp phổ biến trên các ứng dụng C # ASP.NET.

Như Jeff Atwood đã nói, các thủ tục được lưu trữ là ngôn ngữ hợp ngữ của cơ sở dữ liệu và mọi người không có xu hướng viết mã bằng hợp ngữ trừ khi họ cần.

Tôi thường xuyên sử dụng các khung nhìn cụ thể hóa và đôi khi sử dụng CONNECT BY trong Oracle, cả hai đều không tồn tại trong MySQL.

Tôi không có xu hướng sử dụng XML / XSLT trong cơ sở dữ liệu bởi vì, điều đó có nghĩa là tôi đang sử dụng XML và XSLT.

Đối với cấu trúc dữ liệu địa lý hoặc không gian, lý do có lẽ là chúng khó "thu nhận". Đó là một khu vực khá chuyên biệt. Tôi đã đọc hướng dẫn sử dụng MySQL về cấu trúc dữ liệu không gian và tôi chắc rằng nó có ý nghĩa đối với một người có kinh nghiệm GIS sâu rộng nhưng đối với tôi và nhu cầu hạn chế của tôi (có xu hướng đánh dấu vĩ độ / kinh độ của một điểm) thì nó không Có vẻ không đáng để đầu tư thời gian để tìm ra nó.

Một vấn đề khác là nếu bạn vượt ra ngoài ANSI SQL (nhiều) thì bạn chỉ bị ràng buộc phần nào với một nhà cung cấp cơ sở dữ liệu cụ thể và có thể với một phiên bản cụ thể. Vì lý do đó, bạn thường thấy các nhà phát triển ứng dụng sẽ có xu hướng coi cơ sở dữ liệu của họ ở mẫu số chung thấp nhất, có nghĩa là coi chúng như một bãi chứa dữ liệu quan hệ.

Bởi vì các nhà phát triển không biết về SQL. Chúng dựa trên DDL và DML được tạo bởi các công cụ như Hibernate và các cấu trúc cấp độ ngôn ngữ như chú thích JPA. Các nhà phát triển không quan tâm liệu những thứ này có kém hiệu quả kinh khủng hay không vì chúng bị ẩn một cách nhân hậu bởi các cấp nhật ký bình thường và vì DBA không thuộc nhóm phát triển.

Đó là lý do tại sao tôi thích công cụ iBATIS . Chúng giúp bạn viết và hiểu SQL, bao gồm các tính năng cụ thể của DBMS.

Tôi đoán một lý do là sợ nhà cung cấp khóa.

Điều này không được nói thường xuyên, nhưng lợi ích của việc sử dụng các tính năng dành riêng cho nhà cung cấp cần được cân nhắc với chi phí. Chủ yếu là chi phí của việc phải viết lại các phần dựa vào các tính năng dành riêng cho nhà cung cấp cho mọi cơ sở dữ liệu bạn muốn hỗ trợ. Ngoài ra còn có chi phí hiệu suất nếu bạn thực hiện một cái gì đó theo cách có mục đích chung khi nhà cung cấp cung cấp một cách tốt hơn.

Tôi sẽ đưa ra ví dụ này: người ta có thể thấy "lockin" của SQL Server dễ chấp nhận hơn khi người ta nhận ra tất cả những thứ Dịch vụ phân tích, Dịch vụ báo cáo, v.v. có thể làm cho ứng dụng của bạn. Đối với các hệ thống cơ sở dữ liệu thương mại lớn, không chỉ "chỉ" công cụ cơ sở dữ liệu SQL mới cần được tính đến.

"Tại sao các tính năng cơ sở dữ liệu bị bỏ qua".

Bởi vì rất nhiều nhà phát triển được gọi là hoàn toàn không biết gì về quản lý dữ liệu, và điều tệ hơn là họ cũng hoàn toàn không biết gì về sự thiếu hiểu biết của mình. "Không có kỹ năng và không biết về nó", điều này rung chuông cho ai.

Nếu phần mềm của bạn chạy trên phần cứng của máy khách thì bất kỳ thay đổi nào đối với cơ sở dữ liệu (Thủ tục được lưu trữ mới, dạng xem cập nhật, v.v.) sẽ yêu cầu quyền quản trị viên DB. Đây gần như luôn là một vấn đề đối với khách hàng. Tham gia vào nhóm DB sẽ làm phức tạp bất kỳ cập nhật nào bạn cần thực hiện. Có rất nhiều lý do tuyệt vời được trình bày ở đây, nhưng đây là lý do duy nhất tôi cần để tránh đưa mã vào cơ sở dữ liệu như bệnh dịch.

Tôi đoán một lý do là sợ nhà cung cấp khóa. Các tính năng DBMS này không được tiêu chuẩn hóa - ví dụ, các thủ tục được lưu trữ rất đặc trưng cho DB và nếu bạn triển khai nội dung bằng các thủ tục được lưu trữ (thay vì, chẳng hạn, các dịch vụ web được hiển thị qua một tầng trung gian), thì bạn sẽ mãi mãi bị mắc kẹt với DBMS được chọn đầu tiên , (nghĩa là, trừ khi bạn sẵn sàng dành thời gian / tiền bạc để triển khai lại nó trong một DBMS khác nếu bạn muốn thay đổi DBMS).

MySQL.

Khi các ứng dụng web bùng nổ vào cuối những năm 1990 và đầu những năm 2000, MySQL ở phiên bản 3.3 hoặc 4.0 và không hỗ trợ bất kỳ thứ gì trên SELECTcác s đơn giản . Tuy nhiên, nó miễn phí và được cài đặt với hầu hết các bản phân phối Linux. Kết quả là, một thế hệ lập trình viên đã không học về cơ sở dữ liệu và không biết cách sử dụng chúng.

Ngay cả bây giờ MySQL ở mức 5.1 và hỗ trợ hầu hết các tính năng của một hệ thống thương mại, các blog và bài báo cũ tương tự được sử dụng làm mẫu khi một dự án LAMP mới được khởi động và MySQL được triển khai với các bảng MyISAM và chức năng của kỷ nguyên 3.3 .

SQL bị lỗi vì lý do tương tự như Haskell. Thước đo quyết định sự thành công của ngôn ngữ không phải là sự thuần khiết, không phải là sự dễ hiểu của máy tính mà là mức độ khó duy trì các chương trình được viết trong đó.

Chỉ có những con người thất bại với ngay cả ngôn ngữ đơn giản nhất. Có lẽ cứ 10 người thì có 1 người có kỹ năng sử dụng một ngôn ngữ đơn giản như C #. Nhưng trong số 10% đó, chỉ có 1/10 hoặc 1% tổng số người có thể sử dụng hiệu quả các ngôn ngữ như SQL hoặc Haskell.

Bây giờ, SQL là một ngôn ngữ chưa hoàn chỉnh, theo nghĩa là có rất ít thứ bạn có thể làm chỉ với SQL. Bạn sẽ luôn cần một ngôn ngữ khác. Điều đó để lại vai trò gì cho SQL? Các nhà phát triển sẽ hiểu lợi thế của ACID so với lưu trữ tệp phẳng, nhưng bên cạnh đó cơ sở dữ liệu thực sự không có gì để cung cấp cho chúng.

Một vấn đề thứ hai là SQL hiệu quả không tương thích nhiều với Phiên bản nguồn. SQL dường như thực sự được xây dựng dựa trên quan điểm rằng bạn sẽ hiểu đúng ngay lần đầu tiên. Vì vậy, nó không chỉ không phù hợp với các nhà phát triển mà còn không phù hợp với quá trình phát triển.

Việc sửa chữa / triển khai lại tầng giữa dễ dàng hơn so với DBMS.

Điều này có thể phụ thuộc vào kiến ​​trúc của bạn, nhưng đó là lý do của chúng tôi. Kết hợp điều đó với thực tế là chúng tôi có một DBA bận rộn hơn và (có thể) được trả nhiều hơn các nhà phát triển của chúng tôi. Tất cả các nhà phát triển đều biết SQL và một số trong số họ thành thạo ngôn ngữ thủ tục. Nếu một vấn đề sản xuất thực sự phức tạp xuất hiện, các nhà phát triển sẽ làm việc trên tầng giữa dễ dàng và nhanh hơn so với cơ sở dữ liệu, bất kể kiến ​​trúc sẽ tốt hơn theo cách này hay cách khác.

Tôi đã gặp khá nhiều người chỉ không biết rằng các tính năng như vậy tồn tại - họ đã chặt chẽ trong những ngày đầu của mySQL, và họ chưa bao giờ thực sự sử dụng bất kỳ thứ gì khác và họ không theo kịp sự tiến bộ của các bảng lưu trữ mới trong mySQL, thậm chí. Hoặc họ đã học cơ sở dữ liệu ở trường và họ đã không bao giờ quay lại để xem tất cả những thứ họ đã bỏ lỡ.

Họ học SQL tối thiểu để đạt được, và không nhận ra tất cả các phần mở rộng khác nhau mà các RDBMS khác nhau cung cấp.

Trong một dự án, tôi muốn có những cái nhìn cụ thể hóa ... nhưng tôi đang sử dụng Postgres. Tôi muốn sử dụng các kiểu dữ liệu không gian cho một dự án khác, nhưng tôi sẽ phải thực hiện hack hoặc thay đổi cơ sở dữ liệu để đối phó với sự khăng khăng của mySQL rằng chúng không được rỗng. Tôi thậm chí đã phải tìm cách vô hiệu hóa tính nhất quán giao dịch của Oracle để đối phó với các truy vấn chạy dài trên OLTP sẽ không có vấn đề gì trong mySQL.

Tôi thường có thể viết mã xung quanh những thiếu sót của cơ sở dữ liệu cho một vấn đề nhất định, nhưng một phần của vấn đề là chọn công cụ phù hợp cho công việc - trong một dự án hiện tại, chúng tôi đã lãng phí hàng tháng trời vào việc sao chép dữ liệu bởi vì chúng tôi bằng cách sử dụng Postgres, và họ quyết định chọn Slony-1 trước khi họ thực sự biết tất cả những gì chúng tôi sẽ tái tạo.

... Tôi xem câu hỏi này giống như 'tại sao nhiều người không sử dụng tính năng x trong ngôn ngữ y ' - nếu họ không phải là chuyên gia về ngôn ngữ y, họ có thể không biết tính năng x tồn tại.

(và đừng coi đây là sự hỗ trợ để đạt được chứng chỉ DBA ... Tôi đã biết một số DBA của Oracle không thể lập trình theo cách của họ khỏi một cái bao ẩm ướt; tôi đã tham gia tất cả các khóa học trong 8 ngày, nhưng từ chối làm các bài kiểm tra vì tôi không muốn bị gộp chung với nhóm đó)

Tôi nghĩ lý do lớn nhất làm lu mờ tất cả những thứ còn lại là hệ thống cơ sở dữ liệu quan hệ trở nên quan trọng hơn đáng kể khi nhiều ứng dụng đang chia sẻ cùng một dữ liệu. Bài báo nổi tiếng của Codd có tiêu đề "Mô hình dữ liệu quan hệ cho các ngân hàng dữ liệu được chia sẻ lớn " (tôi nhấn mạnh).

Mọi người có xu hướng nghĩ rằng ứng dụng họ đang viết bây giờ sẽ luôn được kiểm soát bởi nhóm của họ; và nó sẽ luôn đáp ứng mọi nhu cầu của những người quan tâm đến dữ liệu do ứng dụng tạo ra. Nếu nhu cầu mới phát sinh, điều đó sẽ được đáp ứng bằng cách thêm một tính năng mới vào ứng dụng hiện có, không phải tạo ứng dụng mới.

Nhưng trong nhiều trường hợp (tất nhiên không phải tất cả; mọi tình huống đều khác nhau), mô hình phát triển đó không hoạt động tốt về lâu dài. Khi dữ liệu do ứng dụng tạo ra tích lũy và trở nên quan trọng hơn đối với doanh nghiệp, những người khác nhau sẽ có những ý tưởng thú vị về cách sử dụng dữ liệu. Khi điều đó xảy ra, nếu bạn không có hệ thống quản lý cơ sở dữ liệu quan hệ, bạn đang gặp một thách thức lớn.

Khả năng mở rộng. Bạn càng giao nhiều công việc cho máy chủ cơ sở dữ liệu, thì nó càng trở nên tắc nghẽn. Sẽ có nhiều khả năng mở rộng hơn khi có cả một hệ thống máy chủ ứng dụng cân bằng tải xử lý dữ liệu và chỉ sử dụng cơ sở dữ liệu như một kho lưu trữ liên tục.

Tôi đã ở trong quá nhiều tình huống mà chính trị công ty ("chúng tôi không được phép truy cập vào SQL Server, vì vậy hãy cài đặt một DBMS kém mạnh hơn như Access để xử lý hàng triệu hàng và nối nó với hàng triệu hàng trong một bảng khác và cho phép tự động hóa quá trình nhập đó .. ") hoặc thậm chí là chính trị kỹ thuật có thể xảy ra (" Tôi biết Access có thể xử lý lượng dữ liệu đó và ngay cả khi không, chúng tôi có thể chia MDB thành nhiều MDB và tham chiếu chúng ..... ")

UGH. Chính trị công ty và chính trị kỹ thuật hoặc thậm chí sự thiếu hiểu biết đã ngăn cản tôi sử dụng nhiều tính năng.

Một ví dụ khác - Tôi thấy không có lý do gì để không sử dụng thủ tục lưu trữ trong một Microsoft cửa hàng 100% nơi SQL Server là các DBMS của sự lựa chọn. Nhưng, vì anh chàng IT cuối cùng sẽ sở hữu giải pháp “nhẹ tay” trên các SP nên tôi đành dùng đến các biện pháp khác. Ý tôi là, có một ví dụ hoàn hảo về lý do tại sao một số "tính năng" đó lại bị họ bỏ qua tại cửa hàng của họ.

Tôi biết một cửa hàng khác vẫn sử dụng DOS Foxpro 2 vì nhân viên IT duy nhất của họ đã viết hệ thống hiện có theo cách đó và đó là cách tất cả những thứ mới sẽ được phát triển. Tại sao? Chúng ta không thể di chuyển cùng với thời gian? Nhiều nhân viên tiếp thị ở đó có một số lời nhắc DOS mở cùng một lúc, với các "công việc" của Foxpro đang chạy trong đó để tạo ra những báo cáo xấu xí nhất mà tôi từng thấy. Nhưng nó hoạt động - tôi sẽ cung cấp cho họ điều đó. Nó hoạt động - họ có 12 triệu hàng trong bảng chính của họ và hơn 50 bảng khác mà họ 'tham gia' với bảng chính đó (rõ ràng không phải tất cả 50 hàng cùng một lúc) nhưng người đàn ông ... đã qua năm 1991! Họ thậm chí không muốn thảo luận về một mục từ danh sách gạch đầu dòng mà bạn đã cung cấp trong câu hỏi của mình.

Những thứ như thế này là lý do tại sao tôi đoán.

Tôi sẽ nói lý do lớn nhất là hầu hết mọi người không biết về chúng. Khi ai đó đã tìm ra giải pháp cho một vấn đề, đó sẽ trở thành giải pháp mặc định cho những vấn đề tương tự. Bảng SELECT * FROM đã hoạt động với rất nhiều người trong một thời gian dài, vì vậy họ không bận tâm đến các cách tiếp cận mới cho các vấn đề cũ.

Lý do khác là đôi khi viết nó bằng mã dễ hơn nhiều so với sử dụng cơ sở dữ liệu. Ý tưởng giống như việc tự giới thiệu sản phẩm của riêng bạn so với mua một bộ phận trên kệ. Sử dụng tính năng được viết sẵn có thể giải quyết vấn đề của bạn nhiều lần, nhưng thỉnh thoảng, bạn cần phải làm điều gì đó nằm ngoài khả năng của những gì các thành phần viết sẵn có thể thực hiện.

Câu hỏi hay và thảo luận tốt.

Một cách khác để đặt nó là "tại sao các DB đối tượng không được bắt kịp?" là mặt còn lại của đồng xu. DB tiếp tục là một thứ trừu tượng khó chịu vẫn có thể xâm nhập vào mọi ứng dụng hiện có, nhưng chúng không tương thích với logic OO của các ứng dụng hiện đại.

Thực sự là một trạng thái kỳ lạ khi chúng tôi ẩn và sao chép chức năng của DB trong ActiveRecord, Hibernate và các phần mềm trung gian khác. Nhưng đây là những gì sẽ xảy ra với các mô hình tại điểm bị đứt ("Sự không phù hợp trở kháng quan hệ đối tượng"). Liệu chúng ta có bao giờ chuyển đổi sang các công nghệ cơ sở dữ liệu tương tự như các ứng dụng OO của chúng ta (ví dụ: DB đối tượng) không?

Câu trả lời là "không lâu nữa" và trong thời gian chờ đợi, DB sẽ bị bỏ qua và thu gọn lại và chỉ được sử dụng để lưu trữ hàng trong nhiều trường hợp, khi tầng giữa phát triển về chức năng để thu hẹp khoảng cách.

Một câu hỏi khác là "tại sao tôi lại làm điều đó trong DB nếu tầng giữa có thể làm được?" Tầng trung lưu đã quen thuộc và luôn đạt được điểm mạnh về tốc độ và chức năng. Một lần nữa, chúng tôi sử dụng tầng giữa để tránh sự không khớp OO-RDMS.

Để nâng cao những gì Christian đã nói, về khả năng mở rộng.

Đơn giản, các RDBM đang được sử dụng nhiều hơn như một kho lưu trữ dữ liệu thuần túy, trong khi logic đã được chuyển sang Máy chủ Ứng dụng. Cấp bổ sung của AS cung cấp cho các nhà phát triển sự linh hoạt hơn so với việc sử dụng RDBMS làm Máy chủ ứng dụng.

Trước đây, trong những ngày cổ điển của Fat Apps và Client Server, DB và Application Server về cơ bản giống nhau. Bạn có logic ứng dụng được nhúng trong mã ứng dụng béo của mình hoặc bạn đã đẩy nó trở lại RDBMS. Nhưng hồi đó, hình thức giao tiếp chính là SQL trực tiếp đến cơ sở dữ liệu.

Ngày nay, các giao thức ứng dụng khác phổ biến hơn (CORBA, DCOM, Remote EJB và ngày càng phổ biến hơn ngày nay là các giao thức kiểu XML / JSON / HTTP-RPC qua HTTP). Hầu hết các cơ sở dữ liệu không phản hồi trực tiếp với các giao thức đó, vì vậy một lớp Ứng dụng được xen vào để chặn các cuộc gọi đó và lớp đó gọi cơ sở dữ liệu.

Nhưng như chúng ta đã học, bây giờ chúng ta sẽ linh hoạt hơn rất nhiều khi đưa logic vào lớp này. Nhiều lựa chọn công cụ hơn, linh hoạt hơn trong bộ nhớ đệm, hoặc chuyển đổi dự phòng, hoặc thậm chí là công nghệ cơ sở dữ liệu (RDMBS, OODBMS, Kho lưu trữ tài liệu như CouchDB). "Mới" đó, tầng thứ 3, mặc dù có thêm sự phức tạp, nhưng lại thêm tính linh hoạt và sức mạnh hơn so với mức độ phức tạp mà nó giới thiệu.

Khi tầng ứng dụng của bạn là một lớp rất mỏng ở phía trên Quy trình được lưu trữ, bạn nên đặt câu hỏi tại sao nó lại ở đó.

Tận dụng cơ sở dữ liệu và tất cả các tính năng của nó là một chiến lược ứng dụng hợp lệ, ngay cả ngày nay. SQL Server, Oracle, v.v., là những phần mềm cực kỳ mạnh mẽ.

Mặc dù vậy, ngay cả khi đó, tầng thứ ba rất hữu ích trong việc bổ sung tính linh hoạt cho một hệ thống hiện đại.

Đối với tôi, lý do không chỉ là các ứng dụng của tôi không có cơ sở dữ liệu, mà là cơ sở dữ liệu định dạng tốt nhất các chức năng CRUD cơ bản. Vâng, cơ sở dữ liệu được tối ưu hóa cao và có thể tạo chú thích HTTP, nhưng tại sao bạn lại làm điều đó? Dịch vụ web / ứng dụng web được tối ưu hóa cho các cuộc gọi HTTP, không phải cơ sở dữ liệu. Cũng giống như một ứng dụng không được thiết kế để kết nối trực tiếp với một tệp dữ liệu và truy xuất dữ liệu. Nó có thể được thực hiện? Có, nhưng tại sao? Đó không phải là điều mà ứng dụng của bạn TUYỆT VỜI.

Cá nhân tôi cảm thấy rằng mọi thứ bạn đã đề cập, bên ngoài các thủ tục được lưu trữ đều thuộc về ứng dụng. Nếu bạn biết kiến ​​trúc của mình là X thì hãy tận dụng các tính năng của X, tải xuống máy chủ DB khi thích hợp, v.v. Nếu nó có thể là X hoặc Y (hoặc Z), thì ứng dụng của bạn phải là bất khả tri, trừ khi bạn cố gắng tạo ra sự an toàn cho công việc bằng cách đảm bảo rằng bạn có thể phải cấu trúc lại ứng dụng :). Tôi nghĩ rằng một chút lười biếng, kết hợp với sự thoải mái có thể liên quan đến nó. Tôi biết tôi muốn làm điều đó trong C # hơn là SQL nếu tôi có thể. . . kỹ năng C # của tôi tốt hơn.

Trước hết: bất kỳ nhà phát triển nào sử dụng ORM đều ngây thơ nếu S / anh ta nghĩ rằng việc sử dụng ORM phủ nhận việc phải có kỹ năng SQL. Hầu hết các ORM tạo SQL thay đổi SQL được tạo ra tùy thuộc vào cách các truy vấn đối tượng được xây dựng. Nhà phát triển sẽ cần phân tích SQL để xem họ có nên thay đổi bất kỳ truy vấn đối tượng nào hay không.

Câu trả lời ngắn gọn: Rất nhiều tính năng đó không thực tế cho việc phát triển OO. Tôi biết rằng các DBA không thích nghe điều đó nhưng, đó là sự thật. Những tính năng đó tốt cho các trường hợp cạnh và hầu hết các ORM tốt như N / Hibernate cho phép bạn cung cấp SQL cho các trường hợp cạnh đó.

Khi nói đến phần lớn được ủy quyền cho CRUD:

Câu trả lời dài: Tôi nghĩ thế giới RDBMS đang trải qua giai đoạn trưởng thành đau đớn và đang tìm thấy vị trí của nó trên thế giới. Sự thật: OOP cũ hơn RDBMS. OOP chỉ là thoát khỏi những nỗi đau ngày càng tăng và trưởng thành. Tôi nghĩ rằng SQL là một ngôn ngữ đã rất trưởng thành, nhưng ý tưởng về những gì một RDBMS nên xử lý chỉ đang được giải quyết. RDBMS là công cụ nắm giữ logic nghiệp vụ cho hầu hết các ứng dụng web cho đến khi Java và C # xuất hiện. Tôi nghĩ bây giờ chúng ta mới bắt đầu cảm nhận được sự điều chỉnh này.

Điều đó đang được nói, tôi không nghĩ rằng bất kỳ nhà thiết kế ORM nào sẽ nói với bạn rằng chất lượng của các câu lệnh sql được cung cấp cho RDBMS không quan trọng.

Khi nói đến KHÔNG PHỤ THUỘC, tôi không có câu trả lời ở đây. Hầu hết các cửa hàng tôi biết vẫn sử dụng DB cho ETL / v.v.

Không có đủ nhà phát triển biết tất cả các tính năng đó ở cấp độ thực sự sẽ tạo ra sự khác biệt đối với một lập trình viên 'trung cấp' bình thường, khi nói đến việc triển khai cùng một logic vào DB hoặc cấp trung bình. Có thể những người thực sự có kiến ​​thức chuyên sâu về các tính năng đó là DBA. Và những vấn đề đó tập trung vào các vấn đề khác hơn là phát triển. Có nhiều nhà phát triển 'bình thường' hơn là DBA. Vì vậy, sẽ rất khó khăn và tốn kém để tìm đúng người cho nhóm của bạn.

Một điểm khác là bạn thường chỉ thu thập kiến ​​thức chuyên sâu về một hệ thống cơ sở dữ liệu chứ không phải tất cả chúng. Vì vậy, bạn có thể có chuyên gia SQL Server hoặc chuyên gia Oracle, nhưng không phải cả hai. Điều này dẫn đến (ở một mức độ nào đó) các lĩnh vực ứng dụng thu hẹp nơi tính chuyên môn hóa cao. Sau đó, thị trường cho các ứng dụng như vậy không phải là lớn, ngay cả khi nó ở đó.

Tôi nghĩ rằng lý do là sự kết hợp của việc nhà cung cấp khóa và thiếu kiến ​​thức của hầu hết người dùng RDBM. SQL là một ngôn ngữ lập trình và việc thành thạo cả ngôn ngữ bạn đang gọi là SQL và SQL sẽ khó hơn nhiều so với việc thông thạo ngôn ngữ này hay ngôn ngữ khác, đặc biệt là vì SQL là một ngôn ngữ đặc biệt độc đáo.

Theo tôi, giải pháp là trừu tượng hóa chức năng cơ sở dữ liệu của bạn thành một lớp tiện ích và trao quyền sở hữu lớp đó cho một vài người dùng biết họ đang làm gì với SQL. Điều này giảm thiểu rủi ro bị khóa nhà cung cấp (nếu bạn chuyển đổi nhà cung cấp, thứ duy nhất được viết lại là lớp). Điều này cũng cung cấp cho các nhà phát triển không phải chuyên gia về SQL một giao diện trừu tượng hóa để họ không phải xử lý cơ sở dữ liệu trực tiếp.

Một mối quan tâm mà tôi đã thấy với việc tận dụng chức năng cơ sở dữ liệu tăng lên là mở rộng quy mô. Nó có vẻ là một đề xuất khó hơn nhiều để chia tỷ lệ tải cơ sở dữ liệu của bạn so với tải máy chủ web / ứng dụng.

Các tùy chọn của bạn bị hạn chế, mở rộng quy mô với phần cứng lớn hơn nhanh hơn (đôi khi chi phí cấp phép cao hơn nhiều) hoặc phức tạp, mở rộng quy mô với các bản sao chỉ đọc, v.v.

Nếu có vấn đề về hiệu suất, tôi muốn chúng ở cấp ứng dụng máy chủ web. Ít nhất thì một trong những tùy chọn của tôi là thêm một máy chủ web khác và phân phối tải.

Tôi không phản đối mã mức cơ sở dữ liệu để giảm thiểu lượng lưu lượng mạng (bản ghi) được gửi giữa máy chủ web và máy chủ cơ sở dữ liệu. Tôi đang tranh luận chống lại các tính năng khác, ví dụ. xử lý logic nghiệp vụ mở rộng ở cấp độ cơ sở dữ liệu.

Một số bài viết lưu ý rằng việc mở rộng quy mô ở lớp ứng dụng sẽ rẻ hơn ở lớp db.

Một cân nhắc khác là các ứng dụng tổng hợp truy cập nhiều kho dữ liệu. Dễ dàng hơn nhiều để viết và duy trì ngôn ngữ truy vấn bất khả tri nền tảng trong cấp ứng dụng so với các truy vấn nền tảng cụ thể riêng biệt trong lớp db.

Bởi vì viết phần mềm hướng đối tượng, bằng ngôn ngữ máy chủ, với các đối tượng ngôn ngữ máy chủ bản địa, sẽ đánh bại việc viết phần mềm thủ tục.

Tôi đã luôn làm việc trên các hệ thống được bán cho nhiều khách hàng và chạy trên phần cứng của khách hàng. Điều này dẫn đến:

• Bạn không biết máy khách sẽ chạy phiên bản phần mềm cơ sở dữ liệu nào.
• Khách hàng có thể không sẵn sàng cập nhật phần mềm cơ sở dữ liệu khi bạn muốn do chi phí giấy phép hoặc do chính sách CNTT.
• Ngay cả những tính năng cơ bản như khung nhìn cụ thể hóa cũng chỉ có trong một số “phiên bản” của phần mềm cơ sở dữ liệu, những khách hàng nhỏ hơn thường không sẵn sàng trả tiền cho phiên bản cao cấp của cơ sở dữ liệu.
• Không sớm thì muộn, một trong những người bán hàng của bạn sẽ đồng ý cho phần mềm của bạn được sử dụng với RDBMS của một nhà cung cấp khác.
• Lựa chọn giữa việc viết logic một lần ở tầng giữa, hoặc ít nhất là PL-SQL và TSQL trong cơ sở dữ liệu là một lựa chọn dễ dàng!
• Bất kỳ thay đổi nào đối với cơ sở dữ liệu (Thủ tục được lưu trữ mới, dạng xem cập nhật, v.v.) sẽ yêu cầu quyền quản trị viên DB; điều này có thể khó hơn rất nhiều trên một số trang web của khách hàng sau đó chỉ cần cập nhật phần mềm của bạn.
• Viết một script để cập nhật cơ sở dữ liệu luôn khó hơn cài đặt một phiên bản mới của ứng dụng. (Hầu hết các hệ thống xây dựng ngày nay đều xuất ra các tệp MSI như một phần của mọi bản dựng)
• Khó hơn để đơn vị mã kiểm tra trong cơ sở dữ liệu sau đó là tầng giữa.
• Khó gỡ lỗi các procs được lưu trữ hơn C #.
• Chỉ vì nó hoạt động trên cơ sở dữ liệu của bạn không có nghĩa là nó sẽ hoạt động trên cơ sở dữ liệu của khách hàng, RDBMS có quá nhiều công tắc thay đổi cách chúng hoạt động - khách hàng luôn có xu hướng đặt chúng theo những cách khác nhau.

Vì vậy, với tất cả những điều trên, lợi ích từ việc sử dụng một tính năng cơ sở dữ liệu phải là rất lớn trước khi nó đáng phải chịu đựng lâu dài.