Liệu business logic tại nhà có trên cơ sở dữ liệu?

Bài viết sẽ giải thích trong trường hợp nào là thích hợp để chuyển business logic của bạn từ bên trong Oracle, IBM DB2, MSSQL Server và các thủ tục lưu trữ của MySQL sang cấp độ ứng dụng có thể mở rộng

Đây là ba lý do chính tại sao business logic được triển khai tốt nhất trong lớp ứng dụng.

Khả năng mở rộng và hiệu suất

Nếu tất cả business logic được thực hiện trong cơ sở dữ liệu dưới dạng các thủ tục được lưu trữ, thì cơ sở dữ liệu sẽ trở thành nút thắt cổ chai. Khi tải bắt đầu tăng, hiệu suất sẽ giảm tương ứng. Việc thực thi một thủ tục được lưu trữ có thể nhanh hơn so với việc thực hiện logic tương đương với mã ứng dụng. Tuy nhiên, khi các thủ tục được lưu trữ được thực thi trên máy chủ cơ sở dữ liệu, ứng dụng sẽ bị giới hạn bởi sức mạnh xử lý của máy chủ cơ sở dữ liệu.

Một biện pháp khắc phục là sử dụng tỷ lệ ngang và để phân tách vật lý các tác vụ xử lý, trong đó việc giảm hiệu năng được trải nghiệm từ các tác vụ cơ sở dữ liệu. Điều này cho phép mở rộng quy mô của lớp ứng dụng độc lập với lớp dữ liệu. Một lớp ORM (Object - relational mapping - là một kỹ thuật/cơ chế lập trình thực hiện ánh xạ cơ sở dữ liệu sang các đối tượng trong các ngôn ngữ lập trình hướng đối tượng như Java, C#…), được thực hiện bởi các công cụ như Hibernate hoặc Oracle TopLink, có thể được sử dụng làm chất kết dính giữa dữ liệu quan hệ và các lớp ứng dụng đối tượng. Bài này giải thích tỷ lệ ngang cho Web 2.0.

Chia tỷ lệ dọc cũng có thể được sử dụng, nhưng điều này phức tạp và tốn kém hơn nhiều. Đó là một giải pháp ngắn hạn giống như chỉ đơn giản là dành nhiều công sức vào vấn đề mà không giải quyết được các nguyên nhân cơ bản.

Phụ thuộc nhà cung cấp

Nhiều công ty lớn không dự đoán sự thay đổi và rất chậm phản ứng với các lực lượng bên ngoài. Điều này đặc biệt rõ ràng khi xem xét cơ sở hạ tầng công nghệ thông tin. Các công ty vẫn đang sử dụng các hệ thống cũ từ 30 - 40 năm trước, chủ yếu là do họ đang bị phụ thuộc vào các nhà cung cấp. Đây là một vấn đề cụ thể đối với cơ sở dữ liệu, vì mỗi nhà cung cấp có ngôn ngữ và chức năng thủ tục được lưu trữ độc quyền của riêng mình. Ví dụ: T-SQL của Oracle 11g PL/SQL và MSSQL Server.

Bạn có thể nghĩ rằng đây không phải là vấn đề nếu bạn xây dựng và duy trì cơ sở dữ liệu cho một công ty duy nhất, nơi mà sự thay đổi trong nhà cung cấp cơ sở dữ liệu phải mất nhiều năm mới được thực hiện. Nhưng điều gì xảy ra khi cơ sở dữ liệu của bạn đột nhiên không còn phù hợp và các nhà quản lý đang yêu cầu thay đổi? Điều này có thể do các yếu tố khác nhau, chẳng hạn như chi phí xoắn ốc hoặc hiệu suất kém. Khi điều đó xảy ra, bạn sẽ thấy rằng sẽ có rất nhiều mã cần phải viết lại. Di chuyển dữ liệu là một chuyện, nhưng chuyển các thủ tục và chức năng lưu trữ lại là một câu chuyện lớn hơn!

Bây giờ, nếu tất cả logic được giữ trong các ứng dụng, thì hãy tưởng tượng việc di chuyển trong hệ sinh thái nhà cung cấp cơ sở dữ liệu sẽ đơn giản hơn rất nhiều, cho phép lựa chọn cơ sở dữ liệu tốt nhất dựa trên nhu cầu hiện tại của bạn, chứ không phải là nhu cầu của 10 - 20 năm trước.

Cơn ác mộng về bảo trì

Các thủ tục được lưu trữ tự tạo một API (Application Programming Interface – giao diện lập trình ứng dụng). Thay đổi API là điều cần tránh, vì nó yêu cầu việc cập nhật mã máy khách sử dụng nó. Điều này có nghĩa cần sự phát triển về thời gian và tiền bạc. Thông thường là khi một bảng hoặc hành vi của một thủ tục được lưu trữ thay đổi, thì một thủ tục lưu trữ mới được thêm vào. Khi bắt đầu, điều này không có vẻ là một vấn đề. Tuy nhiên, khi bạn đang xử lý một hệ thống di sản quy mô trên 30 năm tuổi, thì cuối cùng bạn sở hữu một mớ hỗn độn với các thủ tục đạt tới hàng triệu dòng mã. Khi tính đến ảnh hưởng đến các vấn đề khác, cơ sở mã trở thành một vũng lầy để các nhà phát triển làm việc và dẫn đến hiệu suất, khả năng bảo trì và khả năng mở rộng ngày càng giảm. Điều này tác động trực tiếp đến chi phí kinh doanh.