Tại sao SQL không thể tái cấu trúc hơn? [đóng cửa]

Mọi người đều biết rằng các nhà phát triển mới viết các hàm dài. Khi bạn tiến bộ, bạn sẽ tốt hơn trong việc chia mã của mình thành các phần nhỏ hơn và kinh nghiệm dạy cho bạn giá trị của việc làm như vậy.

Nhập SQL. Đúng, cách suy nghĩ của SQL về mã khác với cách nghĩ về thủ tục về mã, nhưng nguyên tắc này có vẻ như có thể áp dụng được.

Giả sử tôi có một truy vấn có dạng:

select * from subQuery1 inner join subQuerry2 left join subquerry3 left join join subQuery4 

Sử dụng một số ID hoặc ngày, vv

Những truy vấn con đó phức tạp và có thể chứa các truy vấn con của riêng chúng. Không có bối cảnh lập trình nào khác, tôi nghĩ rằng logic cho các truy vấn con phức tạp 1-4 phù hợp với truy vấn chính của tôi kết hợp tất cả chúng. Có vẻ đơn giản đến mức những truy vấn con đó phải được định nghĩa là các khung nhìn, giống như chúng sẽ là các hàm nếu tôi đang viết mã thủ tục.

Vậy tại sao đó không phải là thông lệ? Tại sao mọi người thường viết các truy vấn SQL nguyên khối dài này? Tại sao SQL không khuyến khích sử dụng chế độ xem rộng rãi giống như lập trình thủ tục khuyến khích sử dụng chức năng mở rộng. (Trong nhiều môi trường doanh nghiệp, việc tạo các khung nhìn thậm chí không phải là thứ dễ dàng thực hiện. Có những yêu cầu và phê duyệt cần thiết. Hãy tưởng tượng nếu các loại lập trình viên khác phải gửi yêu cầu mỗi khi họ tạo một hàm!)

Tôi đã nghĩ đến ba câu trả lời có thể:

1. Điều này đã phổ biến và tôi đang làm việc với những người thiếu kinh nghiệm

2. Các lập trình viên có kinh nghiệm không viết SQL phức tạp vì họ thích giải quyết các vấn đề xử lý dữ liệu cứng bằng mã thủ tục

3. Thứ gì khác

Tôi nghĩ vấn đề chính là không phải tất cả các cơ sở dữ liệu đều hỗ trợ Biểu thức bảng chung.

Chủ nhân của tôi sử dụng DB / 2 cho rất nhiều thứ. Các phiên bản mới nhất của nó hỗ trợ CTE, như vậy tôi có thể làm những việc như:

with custs as (
    select acct# as accountNumber, cfname as firstName, clname as lastName,
    from wrdCsts
    where -- various criteria
)
, accounts as (
    select acct# as accountNumber, crBal as currentBalance
    from crzyAcctTbl
)
select firstName, lastName, currentBalance
from custs
inner join accounts on custs.accountNumber = accounts.accountNumber

Kết quả là chúng ta có thể có các tên bảng / trường được viết tắt nhiều và về cơ bản tôi đang tạo các chế độ xem tạm thời, với các tên dễ đọc hơn, sau đó tôi có thể sử dụng. Chắc chắn, truy vấn sẽ lâu hơn. Nhưng kết quả là tôi có thể viết một cái gì đó tách biệt rõ ràng (sử dụng CTE theo cách bạn sử dụng các chức năng để có được DRY) và kết thúc bằng mã khá dễ đọc. Và bởi vì tôi có thể thoát ra các truy vấn con của mình và có một tham chiếu truy vấn con khác, nên nó không phải là "nội tuyến". Đôi khi, tôi đã viết một CTE, sau đó có bốn CTE khác đều tham chiếu nó, sau đó có kết hợp truy vấn chính kết quả của bốn CTE cuối cùng.

Điều này có thể được thực hiện với:

• DB / 2
• PostGreSQL
• Oracle
• Máy chủ MS SQL
• MySQL (phiên bản mới nhất; vẫn còn mới)
• có lẽ là những người khác

Nhưng nó đi một cách lâu dài để làm cho mã sạch hơn, dễ đọc hơn, KHÔ hơn.

Tôi đã phát triển một "thư viện chuẩn" của CTE mà tôi có thể cắm vào các truy vấn khác nhau, giúp tôi bắt đầu bay vào truy vấn mới của mình. Một số trong số họ cũng bắt đầu được các nhà phát triển khác trong tổ chức của tôi chấp nhận.

Theo thời gian, có thể có ý nghĩa để biến một số trong số này thành các chế độ xem, sao cho "thư viện chuẩn" này có sẵn mà không cần phải sao chép / dán. Nhưng các CTE của tôi cuối cùng đã bị điều chỉnh, dù chỉ một chút, cho các nhu cầu khác nhau mà tôi không thể có một CTE duy nhất được sử dụng SO WIDELY, mà không có mod, có thể đáng để tạo một chế độ xem.

Dường như một phần trong sự kìm kẹp của bạn là "tại sao tôi không biết về CTE?" hoặc "tại sao DB của tôi không hỗ trợ CTE?"

Đối với các cập nhật ... vâng, bạn có thể sử dụng CTE nhưng, theo kinh nghiệm của tôi, bạn phải sử dụng chúng trong mệnh đề set VÀ trong mệnh đề where. Sẽ thật tuyệt nếu bạn có thể định nghĩa một hoặc nhiều hơn trước toàn bộ câu lệnh cập nhật và sau đó chỉ có các phần "truy vấn chính" trong tập hợp / mệnh đề nhưng nó không hoạt động theo cách đó. Và không tránh được tên bảng / trường tối nghĩa trên bảng bạn đang cập nhật.

Bạn có thể sử dụng CTE để xóa. Có thể mất nhiều CTE để xác định giá trị PK / FK cho các bản ghi bạn muốn xóa khỏi bảng đó. Một lần nữa, bạn không thể tránh các tên bảng / trường tối nghĩa trên bảng bạn đang sửa đổi.

Khi bạn có thể chọn vào một phần chèn, bạn có thể sử dụng CTE để chèn. Như mọi khi, bạn có thể xử lý các tên bảng / trường tối nghĩa trên bảng bạn đang sửa đổi.

SQL KHÔNG cho phép bạn tạo tương đương với một đối tượng miền, bao bọc một bảng, với getters / setters. Vì thế, bạn sẽ cần sử dụng một loại ORM nào đó, cùng với ngôn ngữ lập trình / OO mang tính thủ tục hơn. Tôi đã viết những thứ thuộc về bản chất này bằng Java / Hibernate.

Việc khóa việc tạo các khung nhìn cơ sở dữ liệu thường được thực hiện bởi các tổ chức hoang tưởng về các vấn đề hiệu suất trong cơ sở dữ liệu. Đây là một vấn đề văn hóa tổ chức, chứ không phải là vấn đề kỹ thuật với SQL.

Ngoài ra, các truy vấn SQL nguyên khối lớn được viết nhiều lần, vì trường hợp sử dụng rất cụ thể nên rất ít mã SQL có thể được sử dụng lại thực sự trong các truy vấn khác. Nếu một truy vấn phức tạp là cần thiết, nó thường dành cho trường hợp sử dụng khác nhau. Sao chép SQL từ một truy vấn khác thường là điểm khởi đầu, nhưng do các truy vấn phụ khác và THAM GIA trong truy vấn mới, cuối cùng bạn sửa đổi SQL đã sao chép vừa đủ để phá vỡ mọi loại trừu tượng mà một "hàm" trong ngôn ngữ khác sẽ được sử dụng cho. Điều này đưa tôi đến lý do quan trọng nhất tại sao SQL khó tái cấu trúc.

SQL chỉ liên quan đến các cấu trúc dữ liệu cụ thể, không phải là hành vi trừu tượng (hoặc trừu tượng theo bất kỳ ý nghĩa nào của từ này). Vì SQL được viết xung quanh các ý tưởng cụ thể, không có gì để trừu tượng hóa thành một mô-đun có thể tái sử dụng. Các khung nhìn cơ sở dữ liệu có thể giúp với điều này, nhưng không đến mức giống như một "hàm" trong ngôn ngữ khác. Một khung nhìn cơ sở dữ liệu không quá trừu tượng vì nó là một truy vấn. Vâng, thực sự, một khung nhìn cơ sở dữ liệu là một truy vấn. Về cơ bản, nó được sử dụng như một bảng, nhưng được thực hiện như một truy vấn phụ, vì vậy một lần nữa, bạn đang xử lý một cái gì đó cụ thể, không trừu tượng.

Đó là với sự trừu tượng mà mã trở nên dễ dàng hơn để cấu trúc lại, bởi vì sự trừu tượng che giấu các chi tiết triển khai từ người tiêu dùng của sự trừu tượng hóa đó. Straight SQL không cung cấp sự phân tách như vậy, mặc dù các phần mở rộng thủ tục cho SQL như PL / SQL cho Oracle hoặc Transact-SQL cho SQL Server bắt đầu làm mờ các dòng một chút.

Điều mà tôi nghĩ rằng bạn có thể thiếu trong câu hỏi / quan điểm của mình là SQL thực thi các hoạt động trên các tập hợp (sử dụng các hoạt động tập hợp, v.v.).

Khi bạn vận hành ở cấp độ đó, bạn, từ bỏ quyền kiểm soát nhất định đối với động cơ. Bạn vẫn có thể buộc một số mã kiểu thủ tục bằng cách sử dụng con trỏ nhưng như kinh nghiệm cho thấy 99/100 lần bạn không nên làm như vậy.

Tái cấu trúc SQL là có thể nhưng nó không sử dụng các nguyên tắc tái cấu trúc mã giống như chúng ta đã sử dụng trong mã cấp độ ứng dụng. Thay vào đó, bạn tối ưu hóa cách bạn sử dụng chính công cụ SQL.

Điều này có thể được thực hiện theo nhiều cách khác nhau. Nếu bạn đang sử dụng Microsoft SQL Server, bạn có thể sử dụng SSMS để cung cấp cho bạn một kế hoạch thực hiện gần đúng và bạn có thể sử dụng nó để xem những bước bạn có thể làm để điều chỉnh mã của mình.

Trong trường hợp tách mã ra thành các mô-đun nhỏ hơn, như @ greg-burghardt đã đề cập, SQL nói chung là một đoạn mã được xây dựng có mục đích và kết quả là. Nó làm một điều mà bạn cần nó để làm và không có gì khác. Nó tuân thủ chữ S trong RẮN, nó chỉ có một lý do để thay đổi / bị ảnh hưởng và đó là khi bạn cần truy vấn đó để làm việc khác. Phần còn lại của từ viết tắt (OLID) không áp dụng ở đây (AFAIK không có nội dung phụ thuộc, giao diện hoặc phụ thuộc như trong SQL) tùy thuộc vào hương vị của SQL mà bạn đang sử dụng, bạn có thể mở rộng một số truy vấn nhất định bằng cách gói chúng trong một hàm thủ tục / bảng được lưu trữ hoặc sử dụng chúng làm các truy vấn phụ, vì vậy, tôi nói rằng nguyên tắc đóng mở vẫn sẽ được áp dụng, theo một cách nào đó. Nhưng tôi lạc đề.

Tôi nghĩ rằng bạn cần thay đổi mô hình của mình về cách bạn đang xem mã SQL. Do tính chất được thiết lập của nó, nó không thể cung cấp nhiều tính năng mà các ngôn ngữ cấp ứng dụng có thể (genericics, v.v.). SQL không bao giờ được thiết kế để trở thành bất cứ thứ gì như vậy, đó là ngôn ngữ để truy vấn các bộ dữ liệu và mỗi bộ là duy nhất theo cách riêng của nó.

Điều đó đang được nói, có nhiều cách để bạn có thể làm cho mã của mình đẹp hơn, nếu khả năng đọc là ưu tiên cao trong tổ chức. Lưu trữ các bit của các khối SQL được sử dụng thường xuyên (các bộ dữ liệu phổ biến mà bạn sử dụng) vào các hàm thủ tục / giá trị bảng được lưu trữ và sau đó truy vấn và lưu trữ chúng trong các biến bảng / bảng tạm thời, sau đó sử dụng các khối đó để nối các phần lại với nhau trong một giao dịch lớn mà bạn viết khác là một lựa chọn. IMHO không đáng để làm điều gì đó như thế với SQL.

Là một ngôn ngữ, nó được thiết kế để dễ đọc và dễ hiểu bởi bất kỳ ai, ngay cả những người không lập trình. Như vậy, trừ khi bạn đang làm một cái gì đó rất thông minh, không cần phải cấu trúc lại mã SQL thành các mảnh có kích thước byte nhỏ hơn. Cá nhân tôi, đã viết các truy vấn SQL lớn trong khi làm việc trên một giải pháp báo cáo / báo cáo ETL / kho dữ liệu và mọi thứ vẫn rất rõ ràng về những gì đang diễn ra. Bất cứ điều gì có thể trông hơi kỳ lạ với bất kỳ ai khác sẽ nhận được một bộ bình luận ngắn gọn cùng với nó để đưa ra một lời giải thích ngắn gọn.

Tôi hi vọng cái này giúp được.

Tôi sẽ tập trung vào "các truy vấn con" trong ví dụ của bạn.

Tại sao chúng được sử dụng thường xuyên như vậy? Bởi vì họ sử dụng cách suy nghĩ tự nhiên của một người: Tôi có bộ dữ liệu này và muốn thực hiện một hành động trên một tập hợp con của nó và tham gia nó với một tập hợp con của dữ liệu khác. 9 trên 10 lần tôi thấy một truy vấn con, nó đã sử dụng sai. Trò đùa của tôi về các truy vấn con là: những người sợ tham gia sử dụng các truy vấn con.

Nếu bạn thấy các truy vấn con như vậy, đó cũng thường là dấu hiệu của thiết kế cơ sở dữ liệu không tối ưu.

Cơ sở dữ liệu của bạn càng được chuẩn hóa, bạn càng nhận được nhiều kết nối, cơ sở dữ liệu của bạn trông giống như một bảng excel lớn, bạn càng nhận được nhiều lựa chọn phụ.

Tái cấu trúc trong SQL thường với một mục tiêu khác: có hiệu suất cao hơn, thời gian truy vấn tốt hơn, "tránh quét bảng". Chúng thậm chí có thể làm cho mã ít đọc hơn nhưng rất có giá trị.

Vậy tại sao bạn thấy rất nhiều truy vấn nguyên khối không được cấu trúc lại?

• SQL, theo nhiều cách không phải là ngôn ngữ lập trình.
• Thiết kế cơ sở dữ liệu xấu.
• Mọi người không thực sự thông thạo SQL.
• Không có quyền đối với cơ sở dữ liệu (ví dụ: không được phép sử dụng chế độ xem)
• Mục tiêu khác nhau với tái cấu trúc.

(đối với tôi, tôi càng có nhiều kinh nghiệm với SQL, các truy vấn của tôi càng ít, SQL có cách để mọi người ở mọi cấp độ kỹ năng hoàn thành công việc của họ bất kể là gì.)

Sự phân chia nhiệm vụ

Theo tinh thần SQL, cơ sở dữ liệu là một tài sản được chia sẻ chứa dữ liệu của công ty và bảo vệ nó là một điều quan trọng. Nhập DBA làm người bảo vệ của ngôi đền.

Tạo một chế độ xem mới trong cơ sở dữ liệu được hiểu là nhằm phục vụ mục đích lâu dài và được chia sẻ bởi cộng đồng người dùng. Trong chế độ xem DBA, điều này chỉ được chấp nhận nếu chế độ xem được chứng minh bằng cấu trúc của dữ liệu. Mọi thay đổi của chế độ xem sau đó có liên quan đến rủi ro cho tất cả người dùng hiện tại, ngay cả những người không sử dụng ứng dụng nhưng đã phát hiện ra chế độ xem. Cuối cùng, việc tạo các đối tượng mới yêu cầu quản lý ủy quyền và trong trường hợp xem, nhất quán với các ủy quyền của các bảng bên dưới.

Tất cả điều này giải thích tại sao các DBA không thích thêm các chế độ xem chỉ dành cho mã của một số ứng dụng riêng lẻ.

Thiết kế SQL

Nếu bạn phân tách một trong những truy vấn phức tạp tốt đẹp của mình, bạn có thể phát hiện ra rằng các truy vấn con thường sẽ cần một tham số phụ thuộc vào truy vấn con khác.

Vì vậy, chuyển đổi các truy vấn con trong chế độ xem không nhất thiết đơn giản như đã nêu. Bạn phải cách ly các tham số biến và thiết kế chế độ xem của bạn để có thể thêm các tham số làm tiêu chí lựa chọn trên chế độ xem.

Thật không may, khi làm như vậy, đôi khi bạn áp đặt để truy cập nhiều dữ liệu hơn và kém hiệu quả hơn trong một truy vấn phù hợp.

Tiện ích mở rộng độc quyền

Bạn có thể hy vọng một số tái cấu trúc, bằng cách chuyển một số trách nhiệm sang các phần mở rộng thủ tục của SQL, như PL / SQL hoặc T-SQL. Tuy nhiên, đây là những người phụ thuộc vào nhà cung cấp và tạo ra sự phụ thuộc về công nghệ. Ngoài ra, các phần mở rộng này thực thi trên máy chủ cơ sở dữ liệu, tạo ra tải xử lý nhiều hơn trên một tài nguyên khó mở rộng hơn nhiều so với máy chủ ứng dụng.

Nhưng vấn đề cuối cùng là gì?

Cuối cùng, sự phân biệt nhiệm vụ và thiết kế SQL với sức mạnh và hạn chế của nó có phải là một vấn đề thực sự không? Cuối cùng, các cơ sở dữ liệu này đã chứng minh xử lý thành công và đáng tin cậy các dữ liệu rất quan trọng bao gồm cả trong các môi trường quan trọng.

Vì vậy, để đạt được một tái cấu trúc thành công:

• xem xét một giao tiếp tốt hơn . Cố gắng hiểu các ràng buộc DBA của bạn. Nếu bạn chứng minh với DBA rằng một quan điểm mới được chứng minh bằng các cấu trúc dữ liệu, thì đó không phải là một cách giải quyết khác và nó không có tác động bảo mật, anh ấy / cô ấy chắc chắn sẽ đồng ý cho phép nó được tạo ra. Bởi vì, sau đó nó sẽ là một lợi ích chung.

• dọn dẹp nhà riêng của bạn trước : Không có gì buộc bạn phải tạo ra nhiều SQL ở nhiều nơi. Tái cấu trúc mã ứng dụng của bạn, để cô lập các truy cập SQL và để tạo các lớp hoặc hàm để cung cấp các truy vấn con có thể sử dụng lại, nếu chúng thường được sử dụng.

• nâng cao nhận thức của nhóm : đảm bảo rằng ứng dụng của bạn không thực hiện các tác vụ có thể được thực hiện hiệu quả hơn bởi công cụ DBMS. Như bạn đã chỉ ra một cách đúng đắn, cách tiếp cận theo thủ tục và cách tiếp cận theo hướng dữ liệu không được làm chủ như nhau bởi các thành viên khác nhau trong nhóm. Nó phụ thuộc vào nền tảng của họ. Nhưng để tối ưu hóa toàn bộ hệ thống, nhóm của bạn cần hiểu toàn bộ hệ thống. Vì vậy, hãy tạo ra nhận thức, để chắc chắn rằng những người chơi ít kinh nghiệm hơn không phát minh lại bánh xe và chia sẻ suy nghĩ DB của họ với các thành viên giàu kinh nghiệm hơn.

Điểm 1 & 3: Lượt xem không phải là cách duy nhất. Ngoài ra còn có các bảng tạm thời, các bảng, biến bảng, cột tổng hợp, CTE, hàm, thủ tục được lưu trữ và có thể các cấu trúc khác tùy thuộc vào RDBMS.

Các DBA (và tôi đang nói là một người vừa là DBA vừa là nhà phát triển) có xu hướng nhìn thế giới theo cách nhị phân khá thường xuyên, thường chống lại những thứ như quan điểm và chức năng do hình phạt hiệu suất nhận thức.

Cuối cùng, nhu cầu về các phép nối phức tạp đã giảm đi khi nhận ra rằng các bảng không chuẩn hóa mặc dù được tối ưu hóa theo quan điểm của NF , có hiệu suất cao.

Ngoài ra còn có xu hướng thực hiện truy vấn phía máy khách với các công nghệ như LINQ mà bạn nêu lên ở điểm 2.

Mặc dù tôi đồng ý rằng SQL có thể thách thức mô đun hóa, những bước tiến lớn đã được thực hiện mặc dù sẽ luôn có sự phân đôi giữa mã phía máy khách và SQL - mặc dù 4GL đã làm mờ đi đôi chút.

Tôi đoán nó thực sự phụ thuộc vào việc các DBA / kiến ​​trúc sư / lãnh đạo công nghệ của bạn sẵn sàng nhượng bao xa về vấn đề này. Nếu họ từ chối cho phép bất cứ điều gì ngoại trừ vanilla SQL có nhiều liên kết, các truy vấn lớn có thể xảy ra. Nếu bạn bị mắc kẹt với điều này, đừng đập đầu vào một bức tường gạch, hãy leo thang. Nhìn chung có nhiều cách tốt hơn để làm mọi thứ với một chút thỏa hiệp - đặc biệt là nếu bạn có thể chứng minh lợi ích.