Ý tưởng tốt để di chuyển logic ra khỏi các câu lệnh SQL?


8

Tôi sẽ mở đầu câu hỏi này bằng cách nói rằng tôi rất mới với nhà phát triển phần mềm chuyên nghiệp.

Tôi làm việc trong một nhóm lấy dữ liệu từ các nhóm khác trong công ty của tôi và biến dữ liệu này thành các báo cáo có thể sử dụng được bởi các nhà điều hành doanh nghiệp.

Trong quá trình chuyển và phân tích dữ liệu, chúng tôi có một số câu lệnh SQL thực hiện nhiều xử lý dữ liệu. Gần như mọi SELECTcông dụng TRIM, SUBSTR, CASTvv rộng rãi để giảm các lĩnh vực với quy mô thích hợp và định dạng. Ngoài ra, có rất nhiều trường hợp đặc biệt được tính bằng cách sử dụng các CASEcâu lệnh trong phạm vi SELECT.

Phần mềm máy chủ Teradata mà chúng tôi sử dụng phát ra các thông báo lỗi khó hiểu. Kết quả là chúng tôi thực hiện rất nhiều phỏng đoán về dữ liệu nào đang phá vỡ câu lệnh SQL nào.

Câu hỏi của tôi là: nó có phải là một ý tưởng tốt để giảm các câu lệnh SQL hơi phức tạp này thành một dạng ít phức tạp hơn mà bỏ qua việc xử lý và xử lý trường hợp đặc biệt, và thay vào đó làm việc này trong một kịch bản hoặc chương trình bên ngoài? Liệu điều này có ý nghĩa gì?

Câu trả lời:


12

Một lợi thế lớn của việc di chuyển mã xử lý ra khỏi SQL của bạn là SQL của bạn trở nên đơn giản hơn rất nhiều để quản lý.

Một bất lợi là nếu bạn từng muốn sử dụng các truy vấn đó trong một số chương trình khác, thì bây giờ bạn phải cung cấp các quy trình xử lý kết quả của mình cho chương trình kia. Nó có thể đơn giản như sao chép một tệp thư viện có chứa các lớp cần thiết, nhưng nó vẫn có nghĩa là mọi thay đổi đối với thư viện phải được truyền bá và tất cả các máy khách được xây dựng lại với thư viện mới.

Tùy chọn khác: Tại sao không sử dụng chế độ xem (hoặc nhiều chế độ xem nếu bạn cần các kết quả được định dạng khác nhau cho các máy khách khác nhau) để chứa hầu hết mã định dạng? Bằng cách đó, bạn có thể nhận được kết quả truy vấn "thô" hoặc kết quả truy vấn được định dạng độc đáo, tùy thuộc vào những gì bạn cần.


3
+1 để đề xuất chế độ xem aa cho phép họ tách SQL định dạng khỏi SQL logic.

2
+1 để xem. Chắc chắn là giải pháp đầu tiên tôi xem xét.
Matt S

6

Tôi đồng ý với đề xuất đã được đưa ra về việc sử dụng Chế độ xem cho logic này. Tôi chỉ muốn thêm một điều nữa về các báo cáo Case. Xin lưu ý rằng việc rút các câu lệnh Case ra khỏi SQL có thể dẫn đến một tác động hiệu năng đáng kể đến hệ thống. Những báo cáo trường hợp đó có thể làm giảm đáng kể lượng dữ liệu được trả về. Chạy bộ lọc Case trong lớp cơ sở dữ liệu thông qua các câu lệnh SQL thường hiệu quả hơn nhiều so với việc kéo tất cả dữ liệu trở lại và thực hiện lọc trong một tập lệnh hoặc chương trình bên ngoài. Nếu bạn đang xem xét điều này, tôi khuyên bạn nên thực hiện một số phân tích dữ liệu và kiểm tra hiệu suất trước khi tiếp tục với giải pháp đó.


4

Thêm một quy trình bên ngoài thường chỉ làm cho hệ thống khó gỡ lỗi hơn, nhưng nó thực sự phụ thuộc vào tình huống. Sử dụng phán đoán của bạn . Xem xét thời gian cần thiết để phát triển / duy trì các dự án ngoài băng.

Bạn đã sử dụng quy trình ETL ? Tôi không có kinh nghiệm với Teradata, nhưng việc tách các bước của bạn cung cấp một cái nhìn rõ ràng hơn nhiều về những gì đang diễn ra. Dưới đây là tổng quan 2 giây:

  1. Trích xuất: Kéo dữ liệu của bạn ra khỏi nguồn và đặt nó vào bộ lưu trữ tạm thời giai đoạn 1. Không thay đổi định dạng của dữ liệu.
  2. Chuyển đổi: Kéo từ giai đoạn 1 và thực hiện tất cả các trường hợp / trim / đế / cast / định dạng, v.v ... mà bạn yêu cầu ở đây. Đặt nó vào giai đoạn 2 lưu trữ tạm thời.
  3. Tải: Kéo từ giai đoạn 2 và đưa tất cả dữ liệu vào bộ lưu trữ đích.

Điều này thường cung cấp đủ thông tin để quản lý thành công loại hệ thống này.


2
À đúng rồi, ETL chính xác là những gì chúng tôi đang làm. Ngoại trừ nó có vẻ giống như ETTTLTLTL với hầu hết các bước Chuyển đổi được thực hiện trong SQL. Tôi nghĩ mục tiêu của tôi là viết các bước chuyển đổi bằng ngôn ngữ có thể mở rộng hơn với khả năng xử lý lỗi tốt hơn Teradata SQL, đây là một thảm họa.
Bryan Glazer

3

Tôi có xu hướng để lại các bit CASE vì chúng liên quan đến logic thực tế của việc sản xuất dữ liệu cho ai đó / thứ để tiêu thụ. Vì vậy, loại bỏ những thứ này có nghĩa là bạn phải gửi lại một bộ dữ liệu lớn hơn và máy khách phải thực hiện một số xử lý trên nó - bây giờ bạn đã chia "logic" báo cáo của mình thành hai lớp riêng biệt và điều này không tốt.

Nhưng tôi sẽ bỏ đi một cục gạch nóng bất kỳ định dạng nào từ mã của bạn (trừ khi đó là một phần cụ thể của các biến vị ngữ THAM GIA, v.v.) vì định dạng đó là công việc của người tiêu dùng ... vì vậy, bất kỳ công cụ báo cáo nào họ sử dụng, có thể là Excel, Crystal, v.v. là tốt trong việc định dạng công cụ trong ngôn ngữ chính xác và tất cả những gì jazz. Hãy để khách hàng làm những gì tốt (hiển thị mọi thứ với màu sắc đẹp) và để máy chủ tập trung vào những gì nó làm tốt nhất - bẻ khóa dữ liệu.


Trong một số môi trường, ứng dụng tiêu thụ dữ liệu cũng có thể đang chạy trên chính máy chủ. Sau đó, câu hỏi trở thành nơi hiệu quả hơn để thực hiện định dạng hoặc các biến đổi khác. Trong một số trường hợp, đặc biệt là khi các giá trị lặp lại phổ biến, thì tổng thể có thể hiệu quả hơn khi cho phép máy chủ sử dụng hàm xác định một lần cho mỗi giá trị gặp phải và chỉ cần sử dụng các kết quả được lưu trong bộ nhớ cache, cho các lần xuất hiện tiếp theo của các giá trị đó. Tại sao có nhiều ứng dụng tất cả tính toán biến đổi giống nhau khi máy chủ có thể làm điều đó một lần cho mọi người.
WarrenT

@WarrenT, đó là một điểm công bằng NHƯNG nếu các hàm này có tính xác định thì tại sao lại bận tâm đến bộ nhớ đệm, chỉ cần tính toán và lưu trữ khi dữ liệu được tạo trong các bảng ... Tôi đã đặt câu hỏi của OP để hiểu hơn về dòng mã định dạng, đó là một ý tưởng tồi cần có trong cơ sở dữ liệu của bạn - bạn cho rằng tất cả các ứng dụng này sẽ muốn dữ liệu mà chúng hiển thị cho người dùng của chúng có cùng định dạng. Điều đó có nghĩa là ví dụ như mọi người trong văn phòng ở nước ngoài của bạn phải xem ngày báo cáo là dd / mm / yyyy chỉ vì cơ sở dữ liệu được bản địa hóa sang tiếng Anh Anh. Chắc chắn bạn có thể đồng ý rằng đây là sự điên rồ?
Stephen Byrne
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.