Các lập trình viên có nên sử dụng SSIS không, và nếu có thì tại sao? [đóng cửa]

Là một nhà phát triển .NET, vì những lý do nào tôi nên thích các gói SSIS hơn là viết mã? Chúng tôi có rất nhiều gói hàng đang được sản xuất ở nơi tôi hiện đang làm việc và chúng là một cơn ác mộng khi phải "viết" (có lẽ là vẽ?) Và bảo trì. Mỗi gói trông giống như một bát mì Ý nhiều màu với các tập lệnh C # và VB.NET được trộn lẫn ở những điểm mà sự trừu tượng bị phá vỡ. Để tìm ra những gì mỗi "Thực thi SQL Task" hoặc "Foreach Loop" làm, tôi phải nhấp đúp vào thứ chết tiệt đó và duyệt qua một cây các giá trị và biểu thức theo nghĩa đen, nằm rải rác trên nhiều tab.

Tôi cởi mở, vì vậy tôi muốn biết liệu có bất kỳ nhà phát triển giỏi nào khác thấy SSIS hiệu quả hơn việc chỉ viết một số mã hay không. Nếu bạn thấy SSIS hiệu quả hơn, vui lòng cho tôi biết lý do.

Tôi sử dụng SSIS hàng ngày để duy trì và quản lý một kho dữ liệu lớn và khối lập phương. Tôi đã kinh doanh 100% trí tuệ và lưu trữ dữ liệu trong hai năm. Trước đó, tôi là nhà phát triển ứng dụng .NET cho 10.

Giá trị của SSIS là một công cụ quy trình làm việc để di chuyển dữ liệu từ vị trí này sang vị trí khác với một số biến đổi hạn chế và phân nhánh có điều kiện trên đường đi. Nếu các gói của bạn chứa nhiều tập lệnh thì nhóm của bạn đang sử dụng SSIS cho các nhiệm vụ sai hoặc không thích SQL hoặc đã mua phải sự cường điệu. Các gói SSIS rất khó gỡ lỗi. Các thành phần tập lệnh là một cơn ác mộng tuyệt đối và chỉ nên được sử dụng để định dạng, lặp lại hoặc là phương sách cuối cùng.

1. Giữ cho các gói của bạn đơn giản, các tác vụ sql và các tác vụ luồng dữ liệu.
2. Làm càng nhiều việc càng tốt bên ngoài SSIS, tốt nhất là trong SQL
3. Giữ các biến của bạn trong một phạm vi toàn cầu duy nhất
4. Giữ SQL của bạn trong các biến hoặc thủ tục lưu trữ, không bao giờ nằm ​​trong dòng
5. Giữ các giá trị biến của bạn trong kho cấu hình, tốt nhất là cơ sở dữ liệu SQL

Tôi đã thử sử dụng SSIS vài lần và từ bỏ nó. IMO dễ dàng hơn nhiều khi chỉ làm tất cả những gì tôi cần trong C #. SSIS quá phức tạp, nó có quá nhiều vấn đề và nó không đáng. Sẽ tốt hơn nhiều nếu dành nhiều thời gian cho việc cải thiện các kỹ năng C # hơn là dành cùng một thời gian cho việc học SSIS - bạn sẽ nhận được nhiều lợi nhuận hơn sau quá trình đào tạo của mình.

Ngoài ra, việc tìm kiếm và duy trì chức năng trong một giải pháp VS dễ dàng hơn rất nhiều. Kiểm tra đơn vị với VS rất dễ dàng. Tất cả những gì tôi cần làm là kiểm tra nguồn trong Subversion và xác minh cách nó tải. Các gói SSIS kiểm tra đơn vị có liên quan rất nhiều để nói một cách nhẹ nhàng.

Bên cạnh đó, có những tình huống khi SSIS âm thầm không điền vào một số cột trong một số hàng, chỉ bỏ qua chúng mà không đặt ra ngoại lệ. Chúng tôi đã dành rất nhiều thời gian để khắc phục sự cố và tìm hiểu điều gì đang xảy ra. Việc phát triển một giải pháp thay thế trong C # chỉ mất chưa đầy một giờ và hoạt động mà không gặp bất kỳ sự cố nào trong hai năm.

Theo ý kiến ​​của tôi - SSIS chỉ dành cho các hoạt động ETL và không được chứa logic nào ngoài phạm vi đó.

Tôi đã có trải nghiệm đáng tiếc khi làm việc trong một dự án mà chúng tôi nghĩ rằng SSIS sẽ là một giải pháp đủ tốt để tổng hợp và kết hợp dữ liệu từ một số nguồn. Điều đáng tiếc là ban đầu nó hoạt động rất tốt nhưng sau đó các yêu cầu thay đổi và chúng tôi (cuối cùng) nhận ra rằng đó là công cụ sai.

có thể chúng tôi đã sử dụng nó không đúng cách nhưng chúng tôi đã gặp rất nhiều khó khăn nếu chúng tôi đã từng thay đổi lược đồ của mình và cuối cùng chúng tôi chỉ sử dụng lại các định nghĩa ORM của mình từ giao diện người dùng để viết một công cụ tùy chỉnh trong C # để thực hiện việc này. Bởi vì chúng tôi đã có datamodel, điều này thật dễ dàng. rõ ràng là YMMV và tôi không phải là chuyên gia SSIS, nhưng trong một trường hợp này, SSIS đã gây ra rất nhiều công việc trùng lặp và đau đầu khi chỉ cần xắn tay áo lên và 'viết mã tay' nó dễ dàng hơn mong đợi.

Vì vậy, tôi sẽ nghĩ đến tính linh hoạt rất nhiều khi xem xét SSIS.

SSIS có vị trí của nó, và vị trí đó không phải là chương trình chung hoặc thay thế cho các thủ tục được lưu trữ. Nó đến từ trường ETL (Trích xuất, Biến đổi và Tải) và đó là vị trí thứ n của nó.

Tên cũ (DTS, Dịch vụ chuyển đổi dữ liệu) và tên mới (SSIS, Dịch vụ tích hợp máy chủ Sql) đều cho thấy rõ ràng đó là một dịch vụ (hoặc tập hợp các dịch vụ) được thiết kế để thao tác dữ liệu nhằm tích hợp cơ sở dữ liệu SQL Server vào các quy trình lớn hơn.

Nếu bạn muốn di chuyển dữ liệu của mình theo lập trình, bạn có thể muốn xem xét Rhino ETL.

Tôi cũng đang làm việc trên khuôn khổ của riêng mình, Fluent ETL , vì tôi thấy SSIS hơi quá tham gia vào các tác vụ dữ liệu đơn giản liên quan đến phát triển, chẳng hạn như tải dữ liệu kiểm tra đơn vị từ tệp CSV.

SSIS không phải là một chương trình. Rất nhiều phần mềm được thực hiện nhanh hơn trong SSIS và bạn nhận được tiến trình và thông tin lỗi rất chi tiết với tư cách là quản trị viên - điều này có thể rất tốt trong các tình huống SSIS được sử dụng để giải quyết, bởi vì đôi khi mọi thứ xảy ra sai và quản trị viên cần rất nhiều thông tin.

Điều đó đang được nói, SSIS không thực sự hữu ích nếu bạn không có nội dung tự học - chúng được thiết kế cho một cái gì đó, việc tham gia quá nhiều vào lập trình chung khiến chúng trở nên tệ hại.