Tôi sẽ không muốn có 200 luồng dữ liệu trong một gói. Thời gian chỉ cần mở ra và xác nhận sẽ khiến bạn già trước thời gian.
EzAPI rất thú vị nhưng nếu bạn chưa quen với .NET và SSIS, ồ không, bạn không muốn điều đó. Tôi nghĩ rằng bạn sẽ dành nhiều thời gian hơn để tìm hiểu về mô hình đối tượng SSIS và có thể xử lý COM hơn là thực sự hoàn thành công việc.
Vì tôi lười biếng, tôi sẽ cắm BIML như một tùy chọn miễn phí mà bạn không liệt kê. Từ một câu trả lời trên SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
- Biml là một con thú thú vị. Varigence sẽ rất vui khi bán cho bạn giấy phép cho Mist nhưng không cần thiết. Tất cả những gì bạn cần là BIDSHelper và sau đó duyệt qua BimlScript và tìm kiếm một công thức gần đúng với nhu cầu của bạn. Khi bạn đã có điều đó, hãy nhấp vào nút menu ngữ cảnh nhạy cảm trong BIDSHelper và whoosh, nó sẽ tạo ra các gói.
Tôi nghĩ rằng nó có thể là một cách tiếp cận cho bạn là tốt. Bạn xác định BIML mô tả cách các gói của bạn hoạt động và sau đó tạo chúng. Trong kịch bản bạn mô tả nơi bạn thực hiện thay đổi và phải sửa N gói, không, bạn sửa định nghĩa của bạn về vấn đề và tạo lại gói.
Hoặc nếu bạn đã đủ quen thuộc với khung công tác thì hãy sử dụng thứ gì đó như EzAPI để sửa và sửa tất cả những thứ bị hỏng. Heck, vì bạn đã gắn thẻ này là năm 2005, bạn cũng có thể dùng thử PacMan nếu bạn cần thực hiện sửa đổi hàng loạt cho các gói hiện có.
Cân nhắc thiết kế SSIS
Nói chung, tôi cố gắng làm cho các gói của mình tập trung vào giải quyết một nhiệm vụ duy nhất (tải dữ liệu bán hàng). Nếu điều đó đòi hỏi 2 luồng dữ liệu, vì vậy hãy là nó. Điều tôi ghét kế thừa là một gói từ trình hướng dẫn xuất nhập với nhiều luồng dữ liệu không liên quan trong một gói. Phân tách chúng thành một cái gì đó giải quyết một vấn đề rất cụ thể. Nó làm cho các cải tiến trong tương lai ít rủi ro hơn khi diện tích bề mặt giảm. Một lợi ích nữa là tôi có thể làm việc với việc tải DimProducts
trong khi minion của tôi đang xử lý SnowflakeFromHell
gói tải .
Sau đó sử dụng (các) gói chính để phối hợp các luồng công việc con. Tôi biết bạn đang ở trên 2005 nhưng bản phát hành SSIS của SQL Server 2012 là đồ ngủ của mèo. Tôi thích mô hình triển khai dự án và sự tích hợp chặt chẽ mà nó cho phép giữa các gói.
TSQL vs SSIS (câu chuyện của tôi)
Đối với cách tiếp cận TSQL thuần túy, trong một công việc trước đó, họ đã sử dụng một công việc 73 bước để sao chép tất cả dữ liệu Informix của họ vào SQL Server. Nó thường mất khoảng 9 giờ nhưng có thể kéo dài đến 12 hoặc hơn. Sau khi họ mua SAN mới, nó đã giảm xuống còn khoảng hơn 7 giờ. Quá trình logic tương tự, được viết lại trong SSIS là một phụ 2 giờ nhất quán. Dễ dàng yếu tố lớn nhất trong việc giảm thời gian đó là sự song song "miễn phí" mà chúng tôi đã sử dụng SSIS. Công việc Đại lý đã chạy tất cả các nhiệm vụ nối tiếp. Gói chính về cơ bản đã chia các bảng thành các đơn vị xử lý (5 bộ tác vụ song song của "chạy bản sao bảng 1", bảng 2, v.v.) trong đó tôi đã cố gắng chia các nhóm thành các đơn vị công việc có kích thước bằng nhau. Điều này cho phép các bảng tham chiếu tra cứu 60 hoặc hơn được nhập nhanh chóng và sau đó quá trình xử lý bị chậm lại khi nó vào "
Điểm cộng khác đối với tôi khi sử dụng SSIS là tôi có được cấu hình "miễn phí", ghi nhật ký và truy cập vào các thư viện .NET cho dữ liệu vuông tôi cần để khoét vào một lỗ tròn. Tôi nghĩ rằng có thể dễ dàng duy trì (bỏ bảo trì) gói SSIS hơn là cách tiếp cận TSQL thuần túy nhờ vào bản chất đồ họa của con thú.
Như mọi khi, phụ cấp của bạn có thể khác nhau.