Trừu tượng hóa cơ sở dữ liệu - nó đang bị quá tải?

Sau khi tiếp xúc với nhiều lớp trừu tượng cơ sở dữ liệu, tôi bắt đầu tự hỏi điểm nào của mỗi thư viện phát minh ra mô hình khác nhau của riêng họ để truy cập dữ liệu. Nhặt một DAL mới có cảm giác như học lại một ngôn ngữ mới, khi mà tất cả những gì tôi muốn làm chỉ là thuyết phục lớp đưa ra một truy vấn SQL mà tôi đã viết trong đầu.

Và đó thậm chí không chạm vào khả năng đọc sau khi thực tế:

# Exhibit A:  A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
    .inner_join(db.ips_x_users.user_id == db.users.id)
    .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)

# Exhibit B:  Another typical DAL
rows = db.ips_x_users
    .join(db.users, on=db.ips_x_users.user_id == db.users.id)
    .filter(db.ips_x_users.ip_addr == '127.0.0.1')
    .select(sort=~db.ips_x_users, limit=10)

# Exhibit C:  A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
             INNER JOIN users ON
                 (ips_x_users.user_id = users.id)
             WHERE ips_x_users.ip_addr = ip
             ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')

Có gì sai với cú pháp SQL chuẩn? Nó được tạo ra cho một mục đích cụ thể, và nó phù hợp với mục đích đó một cách tuyệt đẹp. Có lẽ đó chỉ là tôi, nhưng tôi hiểu đoạn trích C dễ dàng hơn nhiều so với hai đoạn đầu. Các từ khóa được đổi tên và các thủ thuật cú pháp rất dễ thương, nhưng IMO, khi nói đến nó, chúng không giúp việc lấy hàng trở nên dễ dàng hơn cho người viết mã.

Điều này có lẽ dường như là một rant dài, nhưng có là một câu hỏi thực sự ở đây. Vì mọi DAL dường như phát minh ra DSL mới cho các truy vấn thay vì chỉ phân tích cú pháp SQL đã thử và đúng, nên phải có các lợi ích của việc sử dụng cú pháp khác nhau hoặc thiếu sót trong cú pháp SQL tiêu chuẩn mà tôi không nhận ra là có. Bất cứ ai có thể xin vui lòng chỉ ra những gì tôi đang xem ở đây?

Vấn đề cơ bản nhất của việc sử dụng SQL phổ biến là, các truy vấn SQL là các chuỗi, được tạo thành từ một ngôn ngữ khác. Đây là nơi SQL tiêm và các lỗ hổng khác và WTF xuất phát (ví dụ của bạn được chọn khá kém, vì truy vấn của bạn không thực sự có bất kỳ tham số nào).

Vấn đề tiếp theo thực sự là một hệ quả: nếu bạn chỉ có một số SQL được viết trong mã của mình, trình biên dịch không thể làm bất cứ điều gì về nó. Các lỗi như lỗi chính tả trong tên cột sẽ chỉ xuất hiện khi chạy. Về cơ bản, đây là lý do tại sao bạn không muốn chỉ một chuỗi đại diện cho truy vấn của mình trong mã nguồn của mình, nhưng một cái gì đó trình biên dịch có thể phân tích tĩnh để ngăn chặn 95% tất cả các lỗi facepalm.

Và vấn đề cuối cùng xảy ra, khi bạn cố gắng ánh xạ cơ sở dữ liệu quan hệ đến mô hình lập trình và ngữ nghĩa ngôn ngữ của mình: RDBMS không kết hợp tốt với OOP (hoặc truy xuất dữ liệu điều hướng). Trên thực tế, đây là một ý tưởng khá tồi tệ khi kết hợp cả hai, nhưng đó là tất cả những gì DAL hướng đối tượng cho cơ sở dữ liệu SQL (tức là ORM). Nhưng tất cả các lớp trừu tượng này bị lên án để rò rỉ. Tôi nghĩ rằng về cơ bản đây là lý do tại sao có rất nhiều người trong số họ: Bởi vì bạn làm việc với họ, bạn thấy họ thật thiếu sót, bạn đã bắt đầu viết một DAL thực hiện đúng và cuối cùng thất bại.

Vì vậy, trong khi các vấn đề một và hai đề xuất để có các DAL loại bỏ SQL, thì vấn đề thứ ba ngụ ý rằng không có giải pháp thẳng thắn nào về việc có một (ít nhất là cho OOP) và do đó sẽ luôn có một biển DAL với các điểm mạnh và hạn chế khác nhau. Cuối cùng, tất cả những gì bạn có thể làm là cẩn thận chọn một vài cái và bám lấy chúng.

Bạn đang nhìn vào một thực tế rõ ràng rằng không phải tất cả các nền tảng cơ sở dữ liệu đều chấp nhận cùng một cú pháp SQL, do đó, việc nhúng các câu lệnh SQL trong ứng dụng của bạn sẽ không hoạt động cho mọi nền tảng cơ sở dữ liệu. Nếu bạn cần hỗ trợ nhiều nền tảng cơ sở dữ liệu, bạn sẽ phải suy nghĩ lại hầu hết (nếu không phải tất cả) các câu lệnh SQL này.

Tôi cảm thấy như SQL đang trải qua sự thay đổi lớn tương tự con trỏ cách đây 10 năm. Có một nỗ lực liên tục để loại bỏ công việc thủ công với SQL và đưa nó lên mức độ trừu tượng cao hơn. Điều tương tự cũng xảy ra với con trỏ và quản lý bộ nhớ thủ công từ nhiều năm trước.

Vì công việc hiện đang được tiến hành, bạn thích nhìn thấy nhiều cách tiếp cận khác nhau được đề xuất, thử, từ bỏ và tích hợp. Tôi chắc rằng chúng ta sẽ thấy nhiều hơn về nó trước một cách tiếp cận chung hoặc một tiêu chuẩn ngành nếu bạn muốn thể hiện chính nó.

Nó chắc chắn mang lại cho bạn một lợi thế khi bạn có thể thao tác mã truy cập dữ liệu ở cùng cấp độ và với cùng một mô hình bạn áp dụng khi làm việc với mã ứng dụng của bạn.

Trong một vài từ - đơn giản hóa, nhanh nhẹn, nhanh chóng, đây là những mục tiêu.

Joel đã viết một bài báo hay cách đây 10 năm: Đừng để các phi hành gia kiến ​​trúc sợ bạn

Tôi nghĩ đó chính xác là trường hợp. Tôi đã sử dụng lớp trừu tượng trong các ứng dụng của riêng mình kể từ khi tôi tìm thấy một mẫu và tôi dễ dàng thực hiện theo cách này. Nhưng đó là DAL của tôi, tôi biết từng dòng trong mã nguồn => toàn quyền kiểm soát. Nhưng tôi sẽ không đề xuất sử dụng khuôn khổ đó cho bất kỳ ai ngoài nhóm / dự án của tôi.

Khi bạn sử dụng một cái gì đó tương tự, điều quan trọng là phải biết cách triển khai, điều đó có nghĩa là bạn nên dành nhiều thời gian để học thư viện / công cụ. Nếu bạn không có thời gian để học nó - đừng sử dụng. Ngay cả khi nó trông rất dễ dàng ngay từ đầu.