Bộ phận của tôi chuyên chuyển đổi dữ liệu khách hàng vào lược đồ cơ sở dữ liệu của chúng tôi để họ có thể sử dụng phần mềm của chúng tôi.

Ngay bây giờ, chúng tôi có các ứng dụng C # chiếm IDataReader(99% thời gian là một SqlDataReader), thực hiện một số thao tác dọn dẹp và ánh xạ, chèn nó vào một DataRowđối tượng và sau đó sử dụng một SqlBulkCopyđể chèn nó vào cơ sở dữ liệu của chúng tôi.

Đôi khi (đặc biệt là khi cơ sở dữ liệu nguồn chứa hình ảnh dưới dạng varbinaryđối tượng), quá trình này thực sự có thể làm hỏng việc chuyển SQL từ máy chủ sang ứng dụng để sau đó quay lại và quay lại máy chủ.

Tôi cảm thấy rằng nếu chúng tôi viết lại một số chuyển đổi dưới dạng các gói SSIS, nó có thể tăng tốc mọi thứ lên rất nhiều. Tuy nhiên, điều khó khăn nhất mà tôi gặp phải là khi ông chủ của tôi, trong thời trang Not Invented Here , đẩy lùi và nói "Điều gì sẽ xảy ra nếu Microsoft giảm hỗ trợ cho SSIS? Chúng tôi sẽ có tất cả mã lỗi thời này và chúng tôi sẽ bị lừa."

Đây không phải là lần đầu tiên tôi nhấn "Sẽ thế nào nếu họ loại bỏ tính năng đó ...?" trả lời từ ông chủ của tôi. Tôi không có thời gian để viết chuyển đổi theo cách cũ, tự học SSIS và cũng viết nó theo cách mới để chứng minh / kiểm tra các lợi ích (Không ai trong chúng tôi đã sử dụng SSIS nên sẽ có một khoảng thời gian chúng tôi sẽ phải học cách sử dụng nó).

Tôi nên làm gì trong tình huống này? Ngừng đẩy công nghệ mới? Đợi đến khi anh ta rời khỏi bộ phận (tôi là người thứ 2 trong bộ phận sau anh ta, nhưng có thể là nhiều năm trước khi anh ta nghỉ việc / nghỉ hưu)? Tìm một cách mới để khiến anh ta ngừng sợ công cụ của bên thứ 3?

Tôi sẽ giải quyết vấn đề này từ quan điểm quản lý, nhưng hãy nhớ rằng tôi biết tôi không có tất cả các chi tiết. Tôi sẽ tóm tắt những gì tôi thấy:

1. Nhà phát triển cấp trung, chúng tôi sẽ gọi anh ấy là "Scott", khuyên bạn nên viết lại mã kế thừa vào SSIS để cải thiện hiệu suất của quy trình quan trọng ProcessA.
2. ProcessA hiện đang hoạt động trong trạng thái hoạt động mà không có vấn đề lớn nào được biết đến.
3. ProcessA được viết bằng các công cụ độc quyền sử dụng kiến ​​thức phổ biến hoặc có khả năng của bộ lạc để duy trì.
4. Đề nghị viết lại sẽ yêu cầu các công cụ mới để hỗ trợ.
5. Nhân viên hiện tại không có tài liệu kinh nghiệm / kiến ​​thức với các công cụ mới.
6. Các công cụ mới là sự thay thế tương đối gần đây cho các công cụ cũ hơn và hỗ trợ cho các công cụ này có thể thay đổi hợp lý trong vòng 4 quý kinh doanh.

Từ quan điểm này, tất cả những gì tôi thấy là một khoản tiền lớn từ phía công ty để cải thiện một quy trình không bị phá vỡ . Từ quan điểm kỹ thuật tôi có thể thấy sự hấp dẫn, nhưng khi bạn đi thẳng vào nó, điều đó không có ý nghĩa kinh doanh để thực hiện thay đổi này. Nếu bạn có nhân viên có kinh nghiệm về SSIS và các điểm chuẩn để thể hiện sự cải thiện lớn cho quy trình này (hãy nhớ, cải tiến lớn PHẢI tương đương với $$$), kết quả có thể khác một chút. Mặc dù hiện tại, tôi phải đồng ý với ban quản lý (ở đâu đó một cái cây vừa mới chết).

Nếu bạn muốn thúc đẩy việc áp dụng SSIS và có khả năng dẫn đến công cụ tái cấu trúc này, bạn cần có được kinh nghiệm này và đào tạo với các dự án nhỏ hơn, ít quan trọng hơn. Cung cấp điểm chuẩn và hỗ trợ cho SSIS và đảm bảo rằng tất cả các cơ sở hạ tầng và hỗ trợ đã được đưa ra trước khi ban quản lý thậm chí sẽ xem xét thực hiện thay đổi. Khi bạn có công cụ này được sử dụng ở nơi khác, mọi người trong nhóm có kinh nghiệm với việc sử dụng nó và yếu tố "thoải mái" kinh doanh hỗ trợ sẽ không thay đổi và nhổ bật mọi thứ, bạn sẽ có nhiều khả năng thay đổi quan điểm của bạn. Không có những thứ đó, bạn đang sủa sai cây với lập luận đó.

Nghe có vẻ ngu ngốc, đôi khi cách "tốt nhất" không phải là cách tốt nhất.

Chỉnh sửa: Để trả lời một số cập nhật cho câu hỏi, tôi sẽ đăng một sửa đổi nhỏ cho câu trả lời của mình.

Nếu quá trình này gặp phải một số khó khăn, việc viết lại nó vẫn sẽ là một liên doanh tốn kém. Bạn có thể muốn xem xét chi phí tinh chỉnh mã hiện tại sẽ chống lại việc viết lại gói. Xem xét các tác động không chỉ đối với phần mềm mà còn đối với bất kỳ quá trình giao thoa nào của con người. Khi cố gắng để quản lý mua vào để viết lại, nó vẫn sẽ luôn đi xuống tiền. Trừ khi bạn có thể chỉ ra rằng tình trạng khó khăn hiện tại đang tiêu tốn tiền ngay bây giờ hoặc sẽ trở nên lớn trong tổng hợp, ban quản lý vẫn sẽ không thấy được lợi ích. Chi phí này có thể không nhất thiết phải là tài chính. Nếu làm chậm làm ảnh hưởng đến một hệ thống gây ra thời gian chết, đưa ra các vectơ xâm nhập hoặc một số triệu chứng "khó định lượng" khác, bạn có thể cần tìm cách chuyển vấn đề đó thành tương đương rủi ro tiền tệ. Một vectơ xâm nhập, ví dụ, có thể dẫn đến một sự xâm nhập có thể dẫn đến dữ liệu bị mất, bị đánh cắp hoặc bị hỏng. Công ty có thể mất danh tiếng hoặc có thể thất bại trong kiểm toán bảo mật cần thiết. Điều quan trọng là làm cho người quản lý được đề cập để nhận ra những lợi ích có thể định lượng của sự thay đổi.

Phá vỡ mọi thứ là một kỹ năng

Tôi đã làm việc ở quá nhiều nơi bao trùm cuộc tranh luận "nếu nó không bị phá vỡ" đến mức họ không đổi mới, và khi cuối cùng họ buộc phải đổi mới họ sẽ phản ứng lại bằng cách thay đổi mọi thứ . Đơn giản vì họ thiếu kinh nghiệm phá vỡ mọi thứ .

Nó cần sự trưởng thành, kỹ năng và kinh nghiệm để phá vỡ mọi thứ.

Các nhóm phát triển luôn chơi an toàn là dễ nhất để đối thủ vượt qua. Chỉ những đội đã thất bại, mắc sai lầm và những điều bị hỏng mới có thể thực sự đánh giá rủi ro trung thực.

Giữ nguyên hiện trạng

Mặc dù đúng là hệ thống hiện tại đáp ứng các yêu cầu kinh doanh hiện tại. Điều đó không đúng với những thay đổi không lường trước trong tương lai đối với những yêu cầu đó. Như câu tục ngữ cũ nói "vận may thích sự chuẩn bị".

Câu hỏi này không liên quan gì đến SQL hoặc hiệu suất. Đó là về việc đặt câu hỏi "có cách nào tốt hơn không?" và không ngại thử một sự thay thế.

Sếp của bạn bị một trường hợp giữ nguyên trạng .

Người Maya

Không có gì là thực sự làm việc hoàn hảo.

Người Maya tiếp tục trồng thức ăn của họ trên sườn núi. Cho đến khi tất cả các chất dinh dưỡng bị cuốn trôi, và họ không có cách nào để nuôi sống con người của họ. Họ cứ làm mọi thứ theo cách tương tự cho đến khi quá muộn.

Giả sử bạn sẽ có thời gian để khắc phục sự cố khi sự cố xảy ra.

Phải làm gì?

Sếp của bạn bị một trường hợp điều hòa. Những người chấp nhận hiện trạng thường làm như vậy, vì họ thiếu khả năng đưa ra quyết định khó khăn. Khi đối mặt với thử thách, họ sẽ có xu hướng chọn tùy chọn gần nhất với những gì họ quen thuộc.

Sợ hãi đối với anh là một động lực lớn. Nỗi sợ hãi về những điều kiện chưa biết hoặc thay đổi làm lung lay quan điểm của ông về hiện trạng là gì. Anh ta sẽ có xu hướng cố gắng và đưa các điều kiện trở lại bình thường càng nhanh càng tốt.

Bạn cần trình bày ý tưởng theo cách không xung đột. Cố gắng tìm điểm chung giữa những gì bạn muốn làm với những gì đã là hiện trạng. Trình bày các lập luận làm giảm nỗi sợ thay đổi của anh ấy và đưa ra lời trấn an rằng bạn muốn hoàn thành một nhiệm vụ sẽ không gây ra thay đổi đáng kể.

Bước bé

Sẽ là tốt nhất để cung cấp các thay đổi di chuyển dự án theo hướng bạn muốn, nhưng thông qua các dự án gia tăng nhỏ. Thay vào đó, đánh sếp của bạn với câu hỏi lớn về việc hỗ trợ SSIS. Đề nghị tạo một lớp tách trong mã cho phép bạn bổ sung các phương thức "thay thế" để xử lý các bảng có tệp đính kèm lớn. Sau đó, bạn có thể tiến hành đề xuất SSIS với tất cả các điều kiện tiên quyết đã được thêm vào dự án. Điều này làm giảm rủi ro cho sếp của bạn hình dung bằng cách chấp nhận thay đổi.

Nó cần có thời gian

Kinh nghiệm của tôi là những người chấp nhận rủi ro giữ cho một dự án di chuyển, và những người giữ nguyên trạng giống như một bức tường gạch. Kiên trì là lựa chọn duy nhất của bạn để phá vỡ các rào cản của họ. Mong đợi để tiếp tục nghe Không để yêu cầu của bạn.

Khi đến lúc đổi mới. Sếp của bạn sẽ quay sang bạn một cách nhanh chóng, bởi vì bạn thể hiện sự không sợ hãi khi đối mặt với sự thay đổi. Một cái gì đó một người nguyên trạng sẽ tìm kiếm, và bạn sẽ được khen thưởng cho những nỗ lực của bạn. Ngay cả khi không có yêu cầu trước đây của bạn đã được chấp nhận. Bạn sẽ nhanh chóng trở thành một tài sản không thể thay thế trong một công ty phải đối mặt với sự thay đổi bao trùm không có sự thay đổi.

Tôi cảm thấy rằng nếu chúng tôi viết lại một số chuyển đổi dưới dạng các gói SSIS, nó có thể tăng tốc mọi thứ lên rất nhiều. Tuy nhiên, điều khó khăn nhất mà tôi gặp phải là khi ông chủ của tôi, trong thời trang Not Invented Here, đẩy lùi và nói "Điều gì sẽ xảy ra nếu Microsoft giảm hỗ trợ cho SSIS? Chúng tôi sẽ có tất cả mã lỗi thời này và chúng tôi sẽ bị lừa."

Theo tôi, sự hoài nghi về SSIS là hợp lệ.

• Các nhà phát triển dày dạn ghét các hộp đen và có rất nhiều phép thuật xảy ra bên trong gói SSIS.
• Hỗ trợ kiểm soát nguồn cho các gói SSIS rất thiếu. Việc khuếch tán và hợp nhất các tệp dtsx SSIS có thể là một cơn ác mộng nếu các gói dtsx của bạn không đủ mô-đun.
  • Ngược lại, các ứng dụng bảng điều khiển C # rất minh bạch. Bạn luôn có thể làm theo mã để tìm ra điều gì sai.

Ngoài ra, hãy xem xét rằng ông chủ của bạn đang ở trên móc nếu có bất cứ điều gì sai.

• Do đó, anh ta có quyền có ý kiến ​​quan trọng / duy nhất về vấn đề này.

Tôi không có thời gian để viết chuyển đổi theo cách cũ, tự học SSIS và cũng viết nó theo cách mới để chứng minh / kiểm tra các lợi ích (Không ai trong chúng tôi đã sử dụng SSIS nên sẽ có một khoảng thời gian chúng tôi sẽ phải học cách sử dụng nó).

Tôi nên làm gì trong tình huống này? Ngừng đẩy công nghệ mới? Đợi đến khi anh ta rời khỏi bộ phận (tôi là người thứ 2 trong bộ phận sau anh ta, nhưng có thể là nhiều năm trước khi anh ta nghỉ việc / nghỉ hưu)? Tìm một cách mới để khiến anh ta ngừng sợ công cụ của bên thứ 3?

Tôi khuyên bạn nên học SSIS đủ tốt để bạn có thể chứng minh lợi ích của nó.

Và nếu sau khi tự học, bạn thấy rằng SSIS mang lại những lợi thế đáng kể so với cách tiếp cận "truyền thống" hơn và bạn vẫn không thể thuyết phục sếp thay đổi khóa học, thì tôi khuyên bạn nên tìm một công việc khác trong đó bạn có thể sử dụng SSIS.

Phản hồi mà bạn hầu như luôn luôn đi từ hầu hết các loại người quản lý là đại loại như:

"Nó không đáng, nó hoạt động ngay bây giờ và sẽ mất thời gian để thay đổi."

Và nói chung, điều này là hợp lệ. Tuy nhiên, đây không phải lúc nào cũng là một lý lẽ hợp lệ, bởi vì vấn đề cốt lõi xung quanh hội chứng "Không được phát minh ở đây" không phải là liệu mọi thứ có hoạt động hay không, mà công nghệ đó đang được viết lại một cách vô nghĩa , lãng phí giờ của công ty và làm giảm giá trị đáng kể từ sản phẩm được giao.

Bạn cần xác định xem Không phát minh ở đây có thực sự diễn ra hay không trước khi quyết định làm gì. Các công nghệ nội bộ có thể đã được viết cho một lý do .

Dấu hiệu cho thấy Công nghệ được viết lại vì một lý do:

• Công nghệ bạn đang bán cũng là sản phẩm . Nếu bạn là một nhà cung cấp cơ sở dữ liệu, sử dụng mã MySQL, bất kể nó sẽ tiết kiệm được bao nhiêu thời gian, là một ý tưởng nguy hiểm vì nhiều lý do.
• Công nghệ nội bộ được duy trì tốt và giải quyết hiệu quả những thiếu sót của giải pháp sẵn có, trong khi vẫn cung cấp chức năng cơ bản tương đương.
• Công nghệ cải thiện năng suất của toàn bộ nhóm phát triển và các nhà phát triển mới dễ dàng được bán tại sao nó được sử dụng.
• Có những ví dụ khác mà công ty đã áp dụng thành công các công nghệ bên ngoài khác .
• Doanh nghiệp của bạn sẽ bị ảnh hưởng ngay lập tức và nghiêm trọng nếu giải pháp OTS bị ngừng hoặc bị hỏng.
• Doanh nghiệp lớn đến mức có tài nguyên để viết các công cụ chất lượng cao với chi phí thấp (ví dụ: Google có thể viết cơ sở dữ liệu có giá dưới 1000 đô la / giấy phép MS SQL)

Nói cách khác, nhóm hiểu được những hạn chế của việc giải quyết lại các vấn đề đã được giải quyết, nhưng đã đưa ra những ngoại lệ một cách thận trọng khi nó có ý nghĩa từ góc độ kinh doanh.

Dấu hiệu của "Không được phát minh ở đây":

• Có vẻ như mọi thứ đều là nội bộ , và có những lời bào chữa cho mọi thứ: "uh, nó quá chậm", "uh, đó là Microsoft, chúng tôi ghét Microsoft", "uh, nó trông rất khó sử dụng", v.v.
• Đối với các trường hợp công nghệ bên ngoài đang được sử dụng, bạn sẽ nghe thấy "ừ, nó hôi thối và cuối cùng chúng tôi dự định tự viết ".
• Chủ sở hữu của các thành phần đó không có công việc khác mà họ có khả năng làm việc.
• Bạn thấy hầu hết các nhà phát triển mới đến với một bộ kỹ năng được chấp nhận rộng rãi, nhưng phải mất thời gian đáng kể để họ phát triển công cụ nội bộ
• Sau khi phân tích cẩn thận, việc chuyển từ giải pháp OTS sang giải pháp OTS tùy chỉnh hoặc khác sẽ trở nên rõ ràng hơn trong "điều gì xảy ra nếu nó bị ngưng!" kịch bản sẽ có tác động kinh doanh tối thiểu . Ví dụ, nếu String.Join()bị xóa khỏi .NET Framework, việc triển khai lại thành một StringJoin()phương thức tùy chỉnh sẽ không đáng kể.

Nói cách khác, NIH là mô hình của việc không giữ khách quan và thực tế trong trường hợp công nghệ bên ngoài đang được sử dụng thay vì mã của chính mình.

Khi công nghệ được viết lại vì một lý do, đưa ra mối quan tâm của bạn nên được cấp trên khen ngợi và đánh giá cao. Đáng lẽ ra đó là một quyết định cẩn thận khi công nghệ được triển khai và thỉnh thoảng xem xét lại quyết định đó là điều tốt cho doanh nghiệp. Mọi thứ thay đổi theo thời gian và bạn có thể có một điểm hợp lệ. Nếu bạn có thể cung cấp các con số về thời gian lãng phí trong quá khứ, chi phí dự kiến ​​để chuyển đổi và thông tin khác, về lý thuyết, bạn có thể tạo ra một trường hợp để chuyển đổi.

Hiểu rằng với kinh nghiệm của bạn, họ có thể không đồng ý với số của bạn, nhưng bất kể, ít nhất họ cũng nên nghe bạn nói. Nó có thể mất thời gian để có được sự tôn trọng.

Nếu cuộc trò chuyện thậm chí không thể được đưa lên, ngay cả khi bạn là người lịch sự, thì đó có thể chỉ là "Không được phát minh ở đây". Trong trường hợp đó, rất có thể là vấn đề về tính cách hoặc chính trị mà bạn có thể không thể khắc phục dễ dàng. Làm việc trong một môi trường bị sa lầy nặng nề bởi sự tái tạo liên tục là độc hại đối với các nhà phát triển và doanh nghiệp. Chạy.

(Lưu ý bên lề: Trong hầu hết các công ty, luôn có yếu tố NIH, nhưng nó ở mức độ chấp nhận được, và miễn là họ thường xuyên xem lại quy tắc và thông lệ của họ. nó không bao giờ trở thành một vấn đề.)

Vâng, tất cả về phân tích chi phí / lợi ích.

Bạn đạt được gì khi viết lại nó cho SSIS? Tốc độ? Có vấn đề gì không? Nếu đó là một quá trình được thực thi trong GUI và làm lãng phí thời gian của mọi người, thì ừ, có lẽ đó là một ý tưởng tốt để tăng tốc nó, bởi vì tiền đã thay đổi sẽ được lấy lại bởi khách hàng hạnh phúc hơn hoặc nhân viên nội bộ làm công việc của họ thay vì chờ đợi phần mềm. Nhưng nếu một đợt đêm bắt đầu lúc 12 giờ sáng và nó sẽ kết thúc lúc 1 giờ sáng thay vì 6 giờ sáng ... thì không có nhiều điểm. Vâng nhanh hơn 6 lần nhưng không ai cảm nhận được sự khác biệt.

Và ông chủ của bạn có một điểm tốt. Microsoft có xu hướng từ bỏ một số công nghệ của họ. VB6, Linq-to-SQL, ASP classic, COM + ... Đây là một rủi ro với bất kỳ phần mềm nguồn mở nào (và phần mềm nguồn mở quá lớn để tổ chức của bạn duy trì trong trường hợp thiếu cập nhật). Nếu nó là trung tâm của ứng dụng của bạn, bạn nên kiểm soát chặt chẽ nó.

Phần mềm là tất cả về việc tăng thêm giá trị cho khách hàng và cải tiến kỹ thuật không mang lại nhiều lợi ích trong khi đưa ra rủi ro không thực sự hoàn thành vai trò đó.

Phát triển POC (Proof of Concept) và sau đó giới thiệu nó với cấp trên của bạn. POC sẽ giúp bạn xác định bất kỳ lợi ích thực sự nào với công nghệ bạn đang đề xuất. Sau đó, bạn và cấp trên của bạn có thể nói về công nghệ và phát triển những ưu và nhược điểm để thực hiện nó.

Bạn có thể sẽ phải dành thêm một chút thời gian ngoài thời gian làm việc bình thường để phát triển POC.

Là một lưu ý phụ từ quan điểm SSIS, tôi đã sử dụng nó và đã phát triển các gói SSIS. Chúng tôi thực sự đã thay thế một quy trình tải độc quyền bằng các gói SSIS. Chúng tôi chỉ làm điều này vì khách hàng thực tế phàn nàn về thời gian tải. Thời gian tải giảm đáng kể với SSIS và mọi người đã vui vẻ hơn.

SSIS về cơ bản là một quy trình kéo và thả với rất ít chương trình tham gia. Sẽ mất một chút thời gian để tìm hiểu cách hộp đen hoạt động, vì vậy bạn sẽ cần cân nhắc điều đó nếu nhóm của bạn bắt đầu sử dụng nó.

Câu trả lời tốt. Nếu nó không bị hỏng, đừng sửa nó. Tôi sẽ chỉ thêm

• Mặc dù các mối quan tâm về hiệu suất có thể thực sự đúng, từ "có thể" là một lá cờ đỏ. Tôi sẽ làm chẩn đoán hiệu suất trước, vì vậy tôi sẽ có bằng chứng về vấn đề hiệu suất là gì, trước khi cam kết bất kỳ nguồn lực nào để giải quyết nó.

• Khi xem xét "giải pháp" mới nhất từ ​​Microsoft, người ta nên xem xét rằng nhiều người đã bị thiêu đốt bởi những gì MS đã từng chào hàng nhưng sau đó không được chấp nhận và sau đó không được hỗ trợ. Nếu bạn muốn phần mềm chạy trong 10 hoặc 20 năm mà không cần mã hóa chính, bạn nên rất thận trọng về điều đó. Công ty chúng tôi đã bị tổn thương nặng nề theo cách đó.

Doanh thu sẽ là một sự cân nhắc cho ông chủ của bạn. SSIS đang tham gia vào đấu trường DBA so với một lập trình viên có bộ kỹ năng đó. Nếu ứng dụng của bạn không sử dụng SSIS ngoài chuyển đổi ban đầu, tôi không chắc việc học nó và giúp các lập trình viên C # mới tăng tốc vì giống như nhóm của bạn, hầu hết không có kinh nghiệm nào với nó.

Trên thực tế, bạn có thể chỉ ra cho sếp của bạn rằng SSIS là một lớp công nghệ cũ hơn .NET Framework, nếu bạn quay trở lại nguồn gốc của nó là "Khung chuyển đổi dữ liệu" của SQL 7.0.

Trường hợp ông chủ của bạn có thể có một điểm là trong thực tế, SSIS chỉ là một phần của phiên bản Tiêu chuẩn và Doanh nghiệp của Máy chủ Microsoft Sql; đó là một thay đổi khá lớn đối với các khách hàng của bạn để cải thiện, khi ứng dụng của bạn, trong một kịch bản kinh doanh nhỏ, có thể hoàn toàn ổn với Sql Express (hoặc MySQL, đối với vấn đề đó, hoạt động với ADO.NET nhưng không thể sử dụng tích hợp SSIS).

Bây giờ, hãy để tôi được hoàn toàn rõ ràng; IMO, NIH gần như không bao giờ là một điều tốt cho một nhà phát triển phần mềm. Nó khóa bạn ra khỏi rất nhiều công cụ và dịch vụ rất mạnh. Nó cũng đạo đức giả trên khuôn mặt của nó; công ty của bạn đã viết Visual Studio? Làm thế nào về .NET Framework? Máy chủ Sql? Các cửa sổ? Không. Bạn xây dựng phần mềm của mình trên đầu trang của các công cụ và nền tảng bạn đã có (và khách hàng của bạn cũng vậy). Do đó, nếu bạn thấy một công cụ đạt được sự chấp nhận chung và có thể hữu ích trong việc thực hiện công việc kinh doanh cốt lõi của bạn, bạn chấp nhận nó và bạn học cách sống với rủi ro rằng bạn sẽ phải duy trì việc triển khai để theo kịp mới nhất phiên bản của những công cụ đó, hoặc thậm chí thay thế chúng. Tôi cá là ông chủ của bạn trước tiên đã phát triển phần mềm để chạy trên Windows 95/98 hoặc sau đó (nếu không lâutrước đó, như 3.0 / 3.1). Nếu vậy, anh ta đã thấy một nửa tá phiên bản HĐH máy trạm Windows đến và đi, và phải cập nhật phần mềm của mình để chạy trên các nền tảng mới hơn, và anh ta phải đối mặt với một phiên bản khác với XP chính thức EOLed. Trong khi anh ta có thể phàn nàn, đó đơn giản chỉ là chi phí kinh doanh.

Tuy nhiên, thái độ của NIH không nhất thiết phải tuân theo việc từ chối chấp nhận một, hoặc thậm chí một số công nghệ có thể được xem là hữu ích. Những lời từ chối đó có thể dựa trên các phân tích lợi ích chi phí hoàn toàn hợp lệ. Tôi làm việc cho một công ty giám sát và giám sát báo động video và chúng tôi đưa ra quyết định hỗ trợ hoặc không hỗ trợ các công nghệ hoặc sản phẩm mới khác nhau hàng ngày. Thông thường, quyết định chấp nhận một công nghệ mới và nỗi đau của việc đánh bại nó cùng với phần mềm quản lý cảnh báo và trình xem được hỗ trợ hiện có của chúng tôi, chủ yếu dựa trên những gì nó đáng giá cho khách hàng của chúng tôi. Gần đây tôi đã hoàn thành một dự án tích hợp lớn với một loại DVR mới, đơn giản vì một trong những khách hàng lớn nhất hiện tại của chúng tôi cho biết họ đang nâng cấp lên DVR đó từ một sản phẩm DVR có tên tuổi lớn nhưng công nghệ khác, và họ sẽ làm điều đó có hoặc không có sự giúp đỡ của chúng tôi. Mặt khác, chúng tôi thường xuyên từ chối các nhà sản xuất mới, ngay cả các tên hộ gia đình lớn, đơn giản là vì khách hàng của chúng tôi không sử dụng nó và chúng tôi thấy không có giá trị gì khi bắt đầu cung cấp nó, ngay cả khi họ mất một vài khách hàng tiềm năng có nó và không ' t muốn trả tiền cho phiên bản tương tự của chúng tôi.

Tôi không có thời gian để viết chuyển đổi theo cách cũ, tự học SSIS và cũng viết nó theo cách mới để chứng minh / kiểm tra các lợi ích (Không ai trong chúng tôi đã sử dụng SSIS nên sẽ có một khoảng thời gian chúng tôi sẽ phải học cách sử dụng nó).

Đó là một vấn đề, phải không? Bạn đang yêu cầu người khác mạo hiểm năng suất của họ theo ý tưởng của bạn và bạn không sẵn sàng đi ra ngoài để cho họ thấy điều đó xứng đáng. Lãnh đạo kỹ thuật đòi hỏi phải mạo hiểm danh tiếng của bạn hoặc thời gian rảnh của bạn để cho thấy rằng ý tưởng của bạn có giá trị.

Cố gắng nhìn mọi thứ từ quan điểm của sếp. Nghe có vẻ như chức năng bạn đang cố gắng thay thế là cốt lõi đối với những gì phần mềm của bạn làm (xem nhận xét "sai lầm" của anh ấy). Một người quản lý giỏi biết rằng bạn thuê ngoài doanh nghiệp cốt lõi của mình một cách nguy hiểm. Anh ta thực sự lo lắng về việc đặt cược trang trại vào một số công nghệ có thể biến mất trong tương lai. Khi các chức năng cốt lõi có liên quan, Không được phát minh Ở đây thực sự là một điều tốt.

Nếu tốc độ là một tính năng, bạn sẽ phải tìm một cách khác để tăng tốc mọi thứ. Mặt khác, nếu tốc độ quan trọng với bạn hơn là với khách hàng của bạn, tôi nói hãy bỏ nó đi và quên nó đi.

Mặc dù có công với việc Don không sửa những gì không bị hỏng, tôi không đồng ý với câu trả lời được chấp nhận.

Câu trả lời được chấp nhận xuất phát từ quan điểm rằng vấn đề không bị phá vỡ. Từ quan điểm của quản lý cấp trung, điều này là đúng. Nếu việc phân tích chi phí được thực hiện theo thời gian mà các nhà phát triển dành để tạo và duy trì giải pháp ETL trong C # so với việc mua giải pháp vượt trội, thì nó sẽ cho thấy giải pháp C # mất gấp 3 đến 4 lần để tạo ra và duy trì và chi phí nhiều hơn gấp 10 lần (tôi đã tìm tài liệu tham khảo về các con số, nhưng tôi không thể tìm thấy nó).

Trừ khi đó là năng lực cốt lõi của công ty, có rất ít lý do để viết và duy trì chuyển đổi dữ liệu trong C #. Giải pháp cây nhà sẽ chậm, sẽ có lỗi (tức là dữ liệu bị hỏng), sẽ có trường hợp cạnh, sẽ có ít sử dụng lại giữa các lớp ETL, và nó sẽ rất dễ vỡ. Thành thật mà nói, những gì nhà phát triển muốn dành ngày của mình để viết và duy trì ETL trong C #? Tôi đã làm xong. Đó là một đống nhảm nhí. Đó là khoảng cách xa công việc sáng tạo như người ta có thể nhận được.

Sử dụng một công cụ như Informatica, một công ty có hoạt động kinh doanh là ETL. Họ đã làm việc vấn đề này trong hơn 15 năm. Họ đã giải quyết nó. Các công cụ của họ là kéo và thả, khả năng sử dụng lại được tích hợp, cũng như hiệu suất. Hầu hết mọi người (ví dụ như các nhà phát triển cũng không có) có thể tạo ETL bằng công cụ Informatica. Tôi không cố bán Informatica, sử dụng bất kỳ công cụ nào. Chỉ không phát minh lại bánh xe.

Về lâu dài, việc mua một công cụ, chẳng hạn như Informatica hoặc sử dụng SSIS sẽ giúp công ty có khả năng tiết kiệm hàng triệu đô la trong thời gian dài. Và tốt nhất là bạn sẽ không phải duy trì ETL hoặc chịu trách nhiệm về nó khi nó bị phá vỡ.

Tôi đã thử SSIS để thực hiện các nhiệm vụ đơn giản trước đây.

Nó có thể rất khó chịu, vì ngay cả các tác vụ đơn giản cũng sinh ra các sơ đồ phức tạp từ thấp đến trung bình (không, không có cách nào khác để "mã hóa" ngoại trừ các sơ đồ). Và các vấn đề kiểm soát nguồn được chỉ ra bởi câu trả lời của Jim tôi không biết.

Vấn đề bên lề: Vì vậy, để tăng tốc, tôi đề nghị giảm kích thước của các giao dịch cho các hình ảnh của bạn. Nói, cứ 800 thay vì 5000 rocords. Nó có thể giảm kích thước của I / O cần thiết để hỗ trợ giao dịch đó.