우리 부서는 고객 데이터를 데이터베이스 스키마로 변환하여 소프트웨어를 사용할 수 있도록 전문적으로합니다.

현재 C # 응용 프로그램은 IDataReader(시간의 99 % SqlDataReader), 정리 및 매핑을 수행하고, DataRow개체 SqlBulkCopy에 삽입 한 다음 a 를 사용하여 데이터베이스에 삽입하는 C # 응용 프로그램 을 보유하고 있습니다.

때로는 (특히 소스 데이터베이스에 이미지가 varbinary객체 로 포함되어있는 경우 )이 프로세스는 서버에서 앱으로 SQL을 전송 한 후 바로 돌아가서 서버로 돌아갈 수 있습니다.

SSIS 패키지 로 일부 변환을 다시 작성하면 작업 속도가 크게 향상 될 수 있다고 생각합니다. 그러나 내가 계속 겪고있는 가장 큰 벽은 Not Invented Here 패션 에서 상사 가 밀리고 "마이크로 소프트가 SSIS에 대한 지원을 중단하면 어떻게 될까?

"이 기능을 제거하면 어떻게됩니까 ...?"를 누른 것은 이번이 처음이 아닙니다. 내 상사로부터 답변. 나는 변환을 구식으로 쓸 시간이없고, SSIS를 스스로 가르 칠뿐만 아니라, 이점을 입증 / 테스트하는 새로운 방법을 쓸 시간도 없다 (우리 중 누구도 SSIS를 사용하지 않았기 때문에 사용 방법을 배워야합니다).

이 상황에서 어떻게해야합니까? 새로운 기술 추진을 중단 하시겠습니까? 그가 부서를 떠날 때까지 기다립니다 (저는 부서에서 두 번째로 많은 Sr. 사람이지만, 몇 년이 지나면 퇴직 / 퇴직)? 타사 도구에 대한 두려움을 막을 수있는 새로운 방법을 찾으십니까?

나는 경영 관점에서 이것에 균열을 가할 것이지만, 나는 모든 세부 사항이 없다는 것을 알고 있음을 명심하십시오. 내가 본 내용을 요약하겠습니다.

1. 중급 개발자 인 "Scott"는 중요한 프로세스 ProcessA의 성능을 개선하기 위해 레거시 코드를 SSIS로 다시 작성하도록 권장합니다.
2. ProcessA는 현재 알려진 주요 문제없이 작동중인 상태로 작동하고 있습니다.
3. ProcessA는 일반적이거나 부족한 지식을 유지 관리하기 위해 독점 도구로 작성되었습니다.
4. 다시 쓰려면 새로운 도구를 지원해야합니다.
5. 현재 직원은 새로운 도구에 대한 문서화 된 경험 / 지식이 없습니다.
6. 새로운 도구는 비교적 최근의 도구를 대체하는 도구이며 이러한 도구에 대한 지원은 4 분기 내에 합리적으로 변경 될 수 있습니다.

이 관점에서 볼 때, 내가 아는 것은 부서지지 않은 프로세스를 개선하기 위해 회사 측에서 큰 돈을 지출하는 것입니다 . 기술적 인 관점에서 볼 때 나는 호소력을 볼 수 있지만, 당신이 그것을 바로 잡았을 때, 이러한 변화를 만드는 것은 사업 적으로 의미가 없습니다. SSIS 및 벤치 마크에 대한 문서화 된 경험을 보유한 직원이이 프로세스를 대폭 개선했음을 보여주는 경우 (매우 개선은 $$$와 동일해야 함) 결과는 약간 다를 수 있습니다. 하지만 지금은 관리에 동의해야합니다 (나무가 막 죽은 곳).

SSIS 채택을 촉진하고 잠재적으로이 리 팩터를 이끌어 내려면 더 작고 덜 중요한 프로젝트를 통해이 경험과 교육을 받아야합니다. SSIS에 대한 벤치 마크 및 지원을 제공하고 경영진이 변경을 고려하기 전에 모든 인프라 및 지원이 제자리에 있는지 확인하십시오. 다른 곳에서 도구를 사용하고 나면 팀원들이 그 사용법을 경험하고 비즈니스를 지원하는 비즈니스 "편안함"요소가 모든 것을 변화시키고 뿌리 뽑을 수는 없을 것입니다. 그것들이 없으면, 당신은 그 논쟁으로 잘못된 나무를 짖고 있습니다.

어리석은 것처럼 "가장 좋은"방법이 최선의 방법이 아닌 경우도 있습니다.

편집 : 질문에 대한 일부 업데이트에 따라 내 답변에 약간의 수정 사항을 게시합니다.

프로세스가 어떤 종류의 고민을 겪고 있다면 다시 작성하는 데 여전히 많은 비용이 소요됩니다. 기존 코드를 미세 조정하는 데 드는 비용이 패키지를 다시 작성하는 데 드는 비용을 고려할 수 있습니다. 소프트웨어뿐만 아니라 사람의 인터페이싱 프로세스에 미치는 영향을 고려하십시오. 재구매를 위해 경영진을 인수하려고 시도 할 때에도 여전히 비용이 발생합니다. 현재의 고통이 지금 돈을 내고 있거나 전체적으로 커질 것이라는 것을 보여주지 않으면 경영진은 여전히 ​​혜택을 보지 못할 것입니다. 이 비용은 본질적으로 재정적 일 필요는 없습니다. 시스템 속도 저하로 인해 시스템 중단 시간이 발생하거나 침입 벡터 또는 기타 "정량화하기 어려운"증상이 나타나는 경우 해당 문제를 통화 위험 등가로 변환하는 방법을 찾아야 할 수 있습니다. 예를 들어 침입 벡터 침입으로 인해 데이터가 손실, 도난 또는 손상 될 수 있습니다. 회사는 평판을 잃거나 필요한 보안 감사에 실패 할 수 있습니다. 핵심은 문제의 관리자가 변경의 수량 적 이점을 인식하도록하는 것입니다.

속보는 기술이다

나는 그들이 혁신에 실패했다는 점까지“깨지지 않으면”논쟁을 포용하는 너무 많은 곳에서 일했고, 그들이 혁신을 강요 받았을 때 그들은 모든 것을 바꾸어 과도하게 반응했다 . 그들이 물건을 깨는 경험이 부족 하기 때문에 단순히 .

문제를 해결하려면 성숙함, 기술 및 경험이 필요합니다.

항상 안전하게 플레이하는 개발 팀이 경쟁 업체보다 훨씬 쉽습니다. 실패하고 실수를 저질렀던 팀만이 정직한 위험 평가를 수행 할 수 있습니다.

상태 유지

사실이지만 현재 시스템은 현재 비즈니스 요구 사항을 충족합니다. 이러한 요구 사항에 대한 예기치 않은 변경 사항이 미래에는 해당되지 않습니다. 오래된 속담이 말했듯이 "운은 준비된 것을 선호합니다".

이 질문은 SQL 또는 성능과 관련이 없습니다. "더 나은 방법이 있습니까?"라는 질문을하는 것입니다. 대안을 시도하는 것을 두려워하지 않습니다.

당신의 상사는 상태 유지 유지 사건으로 고통 받고 있습니다 .

마야의

진정으로 완벽하게 작동하는 것은 없습니다.

마야인들은 산 쪽에서 계속 음식을 재배했습니다. 모든 영양소가 씻겨 질 때까지 사람들에게 먹이를 줄 방법이 없었습니다. 그들은 너무 늦을 때까지 같은 방식으로 일을 계속했습니다.

문제 자체가 잘못되었을 때 문제를 해결할 시간이 있다고 가정하면 실수입니다.

무엇을해야합니까?

당신의 상사는 컨디셔닝 사건으로 고통 받고 있습니다. 현 상태를 받아들이는 사람들은 어려운 결정을 내릴 능력이 없기 때문에 종종 그렇게합니다. 도전에 직면했을 때 그들은 익숙한 것에 가장 가까운 옵션을 선택하는 경향이 있습니다.

그를 두려워하는 것은 큰 동기 부여입니다. 미지의 상황이나 변화하는 상황에 대한 두려움은 현상 유지에 대한 그의 시각을 흔들어 놓는다. 그는 가능한 빨리 조건을 정상으로 되돌리려 고 시도하는 경향이 있습니다.

충돌하지 않는 방식으로 아이디어를 제시해야합니다. 이미 현상 유지와 관련하여 공통적 인 근거를 찾으십시오. 그의 변화에 ​​대한 두려움을 줄이는 주장을 제시하고 중대한 변화를 일으키지 않는 과제를 완수하고자하는 확신을 제공하십시오.

아기 발걸음

프로젝트를 원하는 방향으로 이동하지만 작은 증분 프로젝트를 통해 변경하는 것이 가장 좋습니다. 그런 다음 SSIS 지원에 대한 큰 의문으로 상사를 때리십시오. 큰 첨부 파일이있는 테이블을 처리하기 위해 "대체"방법을 플러그인 할 수있는 분리 레이어를 코드에 제공하십시오. 그런 다음 모든 필수 구성 요소가 이미 프로젝트에 추가 된 상태로 SSIS를 권장하도록 진행할 수 있습니다. 이렇게하면 변경 사항을 수락하여 상사가 구상하는 위험이 줄어 듭니다.

시간이 걸린다

저의 경험은 위험 감수자들이 프로젝트를 계속 움직이게하고 현 상태 유지 자들은 벽돌 벽과 같습니다. 지속성은 그들의 장벽을 무너 뜨리는 유일한 옵션입니다. 계속 듣게 기대 없음 귀하의 문의에.

때가 오면 혁신. 변화에 직면 할 때 두려움을 나타내지 않기 때문에 상사가 당신에게 빨리 돌릴 것입니다. 현 상태의 사람이 찾고있는 무언가, 당신은 당신의 노력에 대한 보상을받을 것입니다. 이전 문의 중 어느 것도 수락되지 않은 경우에도 마찬가지입니다. 변화가없는 변화에 직면 한 회사에서는 빠르게 대체 할 수없는 자산이됩니다.

SSIS 패키지로 일부 변환을 다시 작성하면 작업 속도가 크게 향상 될 수 있다고 생각합니다. 그러나 내가 계속 겪고있는 가장 큰 벽은 상사가 Not Invented Here 방식으로 되돌아 가서 "Microsoft가 SSIS에 대한 지원을 중단하면 어떻게됩니까?

제 생각에는 SSIS에 대한 회의론이 유효합니다.

• 노련한 개발자는 블랙 박스를 싫어하며 SSIS 패키지 내부에서 발생하는 많은 마술이 있습니다.
• SSIS 패키지에 대한 소스 제어 지원이 부족합니다. dtsx 패키지가 충분히 모듈화되어 있지 않으면 SSIS dtsx 파일의 확산 및 병합은 악몽이 될 수 있습니다 .
  • 반대로 C # 콘솔 응용 프로그램은 매우 투명합니다. 항상 코드를 따라 무엇이 잘못되었는지 알아낼 수 있습니다.

또한 문제가 발생하면 사장님이 전화를 걸고 있다고 생각하십시오.

• 따라서 그는 그 문제에 대한 우선적이거나 유일한 의견을 가질 권리가 있습니다.

나는 변환을 구식으로 쓸 시간이없고, SSIS를 스스로 가르 칠뿐만 아니라, 이점을 입증 / 테스트하는 새로운 방법을 쓸 시간도 없다 (우리 중 누구도 SSIS를 사용하지 않았기 때문에 사용 방법을 배워야합니다).

이 상황에서 어떻게해야합니까? 새로운 기술 추진을 중단 하시겠습니까? 그가 부서를 떠날 때까지 기다립니다 (저는 부서에서 두 번째로 많은 Sr. 사람이지만, 몇 년이 지나면 퇴직 / 퇴직)? 타사 도구에 대한 두려움을 막을 수있는 새로운 방법을 찾으십니까?

SSIS 의 이점을 충분히 입증 할 수 있도록 SSIS를 충분히 배우는 것이 좋습니다 .

그리고 자율 학습 후에 SSIS가보다 "전통적인"접근 방식에 비해 상당한 이점을 제공하지만 여전히 상사에게 코스 변경을 설득시킬 수 없다면 다른 방법을 찾아 볼 것을 권장합니다. SSIS를 사용하십시오.

대부분의 관리자 유형에서 거의 항상 응답은 다음과 같습니다.

"가치가없고, 지금 작동하며, 변경하는 데 시간이 걸립니다."

그리고 일반적으로 이것은 유효합니다. 그러나 "여기에 발명되지 않음"증후군을 둘러싼 핵심 문제는 일이 작동하는지 작동하지 않는지가 아니라 기술이 무의식적으로 다시 작성 되고 회사 시간을 낭비하며 상당한 가치를 떨어 뜨리기 때문에 항상 유효한 주장은 아닙니다. 배송되는 제품에서

수행 할 작업을 결정하기 전에 여기서 발명하지 않았는지 실제로 확인해야합니다. 내부 기술은 어떤 이유로 작성 되었을 수 있습니다 .

기술이 이유를 위해 다시 쓰여졌다는 표시 :

• 당신이 판매하는 기술도 제품 입니다. MySQL 코드를 사용하는 데이터베이스 공급 업체 인 경우 시간이 얼마나 걸리더라도 여러 가지 이유로 위험한 생각입니다.
• 내부 기술은 잘 유지 관리되며 상용 솔루션의 단점 을 효과적으로 해결 하면서도 비슷한 기본 기능을 제공합니다.
• 이 기술 은 전체 개발 팀 의 생산성 을 향상 시키며 , 새로운 개발자는 왜 사용 중인지 쉽게 팔 수 있습니다.
• 회사가 다른 외부 기술을 성공적으로 채택한 다른 사례도 있습니다 .
• OTS 솔루션이 중단되거나 중단되면 비즈니스에 즉각 적이고 심각한 영향을 미칩니다.
• 비즈니스 규모가 너무 커서 고품질 도구를 저렴한 비용으로 작성할 수있는 리소스가 있습니다 (예 : Google은 $ 1000 / 시트 MS SQL 라이센스 미만의 데이터베이스를 작성할 수 있음)

다시 말해, 팀은 이미 해결 된 문제를 해결하는 데 따른 단점을 이해하지만 비즈니스 관점에서 의미가있는 예외는 적절하게 판단했습니다.

"여기서 발명되지 않음"의 징후 :

• 것 같다 모든 내부에 등, "어, 사용하기 정말 열심히 보인다", "어, 마이크로 소프트의, 우리는 마이크로 소프트를 싫어", "어,이 너무 느린했다", 및 모두를위한 변명이있다
• 외부 기술을 사용하는 경우에는 "그렇습니다. 악취가 나고 결국 자체 작성을 계획 하고 있습니다"라는 음성이 나옵니다 .
• 해당 구성 요소의 소유자 는 다른 작업 을 수행 할 수 없습니다 .
• 대부분의 새로운 개발자가 널리 수용되는 기술 세트를 사용하고 있지만 내부 툴링을 시작하는 데 상당한 시간이 걸립니다.
• 신중하게 분석 한 후 "중단되면 어떻게 됩니까? " 에서 OTS 솔루션에서 커스텀 또는 다른 OTS 솔루션으로 전환하는 것이 어려워집니다 . 시나리오는 최소한의 비즈니스 영향을 미칩니다 . 예를 들어 String.Join().NET Framework에서 제거 된 경우 사용자 지정 StringJoin()메서드 로 다시 구현하는 것은 쉽지 않습니다.

즉, NIH는 자체 코드 대신 외부 기술을 사용하는 경우 객관적이고 현실적으로 유지하지 못하는 패턴입니다.

기술이 어떤 이유로 다시 쓰여질 때, 당신의 우려를 불러 일으키는 것은 상사에 의해 칭찬되고 감사되어야합니다. 기술이 구현 될 때 신중한 결정이되어야했으며, 결정을 검토하는 것이 때때로 비즈니스에 도움이되었습니다. 시간이 지남에 따라 상황이 바뀌고 유효한 포인트가있을 수 있습니다. 과거에 낭비 된 시간, 예상 전환 비용 및 기타 정보에 대한 숫자를 제공 할 수 있다면 이론적으로 전환 사례를 만들 수 있습니다.

당신의 경험에 비추어 볼 때, 그들은 당신의 숫자에 동의하지 않을 수도 있지만, 적어도 당신의 말을 들어야합니다. 존경을 얻는 데 시간이 걸릴 수 있습니다.

대화를 꾸준히 할 수 없다면, 예의 바르게 행동하더라도 "여기에 발명되지 않음"일 수 있습니다. 어떤 경우에는 쉽게 고칠 수없는 성격이나 정치적 문제 일 가능성이 높습니다. 끊임없는 재창조로 인해 크게 위축 된 환경에서 작업하는 것은 개발자와 비즈니스에 유독합니다. 운영.

(측면 참고 : 대부분의 회사에는 NIH의 요소가 항상 있지만, 허용 수준에 있으며 규칙과 관행을 정기적으로 검토하는 한, 장기적으로는 어느 정도 유죄입니다. 결코 문제가되지 않습니다.)

비용 / 이익 분석에 관한 모든 것.

SSIS에 다시 쓰면 무엇을 얻을 수 있습니까? 속도? 그게 그렇게 중요한 건가? GUI에서 프로세스가 실행되어 모든 사람이 시간을 낭비한다면 프로세스 속도를 높이는 것이 좋습니다. 변경하는 데 드는 돈은 더 행복한 고객이나 내부 직원이 대신 작업을 수행하여 얻는 것이기 때문입니다. 소프트웨어를 기다리는 중입니다. 그러나 밤 배치가 오전 12시에 시작하여 오전 6 시가 아닌 오전 1시에 끝나는 경우 ...별로 중요하지 않습니다. 예, 6 배 빠르지 만 아무도 차이를 느끼지 않습니다.

그리고 당신의 상사는 좋은 지적을 가지고 있습니다. Microsoft는 일부 기술을 포기하는 경향이 있습니다. VB6, Linq-to-SQL, ASP classic, COM + ... 이것은 오픈 소스가 아닌 소프트웨어 (그리고 조직이 업데이트가 부족한 경우 조직이 유지하기에는 너무 큰 오픈 소스 소프트웨어)의 위험입니다. 응용 프로그램의 중심에있는 경우 응용 프로그램을 엄격하게 제어해야합니다.

소프트웨어는 고객에게 가치를 더하는 것입니다. 위험을 도입하면서 많은 이점을 얻지 못하는 기술 향상은 실제로 그 역할을 수행하지 않습니다.

POC (Proof of Concept)를 개발하고이를 상급자에게 시연하십시오. POC는 제안하는 기술의 실질적인 이점을 판단하는 데 도움이됩니다. 그러면 귀하와 귀하의 상사는 기술에 대해 이야기하고 기술을 구현할 장단점을 개발할 수 있습니다.

POC를 개발하려면 정상적인 근무 시간 외에 추가 시간을 소비해야 할 것입니다.

SSIS 관점에서 부수적으로, 나는 그것을 사용하고 SSIS 패키지를 개발했습니다. 실제로 SSIS 패키지를 사용하여 독점적 인로드 프로세스를 교체했습니다. 실제 고객이로드 시간에 대해 불만을 표시했기 때문에이 작업 만 수행했습니다. SSIS로로드 시간이 크게 줄어들었고 모두가 행복해졌습니다.

SSIS는 기본적으로 프로그래밍이 거의없는 드래그 앤 드롭 워크 플로입니다. 블랙 박스 작동 방식을 배우는 데 시간이 걸리므로 팀에서 블랙 박스를 사용하기 시작하면 고려해야합니다.

좋은 답변입니다. 고장 나지 않았다면 고치지 마십시오. 나는 단지 추가 할 것이다

• 성능 문제가 실제로 사실 일 수도 있지만, 그 단어 "마음"은 위험 신호입니다. 먼저 성능 진단을 수행하므로 성능 문제를 해결하기 위해 리소스를 커밋하기 전에 성능 문제가 무엇인지 증명해야합니다.

• Microsoft의 최신 "솔루션"을 고려할 때 MS가 한때 선전했지만 그 이후에는 더 이상 사용되지 않으며 지원되지 않는 사람들로 인해 많은 사람들이 화상을 입 었음을 고려해야합니다. 주요 레코딩없이 소프트웨어를 10 년 또는 20 년 동안 실행하려면 매우주의해야합니다. 우리 회사는 그렇게 심하게 다 쳤어요.

이직 은 상사에게 고려해야 할 사항입니다. SSIS는 해당 기술을 보유한 프로그래머와 비교하여 DBA 분야에 진출하고 있습니다. 응용 프로그램이 초기 변환 이후에 SSIS를 사용하지 않는 경우 팀과 마찬가지로 경험이 많지 않기 때문에 응용 프로그램을 배우고 새로운 C # 프로그래머의 속도를 높이는 것이 타당하지 않습니다.

SQL 7.0의 "데이터 변환 프레임 워크"로 다시 돌아 가면 SSIS가 .NET Framework보다 오래된 기술 계층이라는 사실을 상사에게 지적 할 수 있습니다.

상사가 중요한 점은 SSIS가 Microsoft Sql Server Standard 및 Enterprise 버전의 일부일뿐입니다. 소규모 비즈니스 시나리오에서 응용 프로그램이 Sql Express (또는 MySQL과 관련하여 ADO.NET과 작동하지만 완벽하지는 않음)를 사용하면 클라이언트가 조롱 할 수있는 큰 변화입니다. SSIS 통합 사용).

이제 완전히 명확하게하겠습니다. IMO, NIH는 소프트웨어 개발 하우스에 거의 좋은 것이 아닙니다. 매우 강력한 도구와 서비스를 차단합니다. 그것은 또한 얼굴에 위선적입니다. 회사에서 Visual Studio를 작성 했습니까? .NET Framework는 어떻습니까? SQL Server? 윈도우? 아닙니다. 이미 보유한 도구 및 플랫폼 위에 소프트웨어를 구축합니다 (클라이언트도 마찬가지입니다). 따라서 일반적으로 수용되고 핵심 비즈니스를 수행하는 데 유용 할 수있는 도구를 발견 한 경우이를 채택하면 최신 상태를 유지하기 위해 구현을 유지 관리해야 할 위험에 처하게됩니다. 해당 도구의 버전을 바꾸거나 대체 할 수도 있습니다. 그렇지 않으면 나는 (당신의 상사는 Windows 95/98 또는 그 부근에서 실행하는 소프트웨어를 개발 내기 긴그 전에는 3.0 / 3.1). 그렇다면 그는 6 가지 버전의 Windows 워크 스테이션 OS가왔다 갔다하면서 새로운 플랫폼에서 실행되도록 소프트웨어를 업데이트해야했으며 XP는 공식적으로 EOLed를 사용하는 또 하나의 소프트웨어를 사용하고 있습니다. 그가 불평 할 수도 있지만, 그것은 단순히 사업 비용입니다.

그러나 NIH 태도가 도움이 될 수있는 하나 또는 여러 가지 기술에 대한 거부를 반드시 따르는 것은 아닙니다. 이러한 거부는 완벽하게 유효한 비용 편익 분석을 기반으로 할 수 있습니다. 비디오 감시 및 경보 모니터링 회사에서 근무하며 매일 다양한 신기술 또는 제품을 지원할지 여부를 결정합니다. 일반적으로 새로운 기술을 채택하기로 결정하고 기존의 지원되는 뷰어 및 경보 관리 소프트웨어와 함께 기술을 도입하는 데 따르는 어려움은 주로 고객에게 가치가있는 것을 기반으로합니다. 최근 새로운 유형의 DVR과 큰 통합 프로젝트를 마쳤습니다. 기존의 가장 큰 고객 중 한 명이 기술적으로 뒤 떨어진 다른 DVR 제품에서 해당 DVR로 업그레이드하고 있다고 말했기 때문입니다. 그들은 우리의 도움을 받거나받지 않고 그것을 할 것입니다. 반면에, 우리는 새로운 제조업체, 심지어 주요 세대 이름까지도 정기적으로 거부합니다. 단순히 고객이 사용하지 않기 때문에이를 제공 할 가치가 없기 때문입니다. 똑같은 버전의 비용을 지불하고 싶지 않습니다.

나는 변환을 구식으로 쓸 시간이없고, SSIS를 스스로 가르 칠뿐만 아니라, 이점을 입증 / 테스트하는 새로운 방법을 쓸 시간도 없다 (우리 중 누구도 SSIS를 사용하지 않았기 때문에 사용 방법을 배워야합니다).

그것은 일종의 문제입니까? 당신은 다른 사람들에게 당신의 아이디어에 대한 그들의 생산성을 위험에 빠뜨리라고 요구하고 있으며, 그 가치가 있다는 것을 보여주기 위해 사지로 나 가려고하지 않습니다. 기술 리더십은 당신의 아이디어가 가치가 있음을 보여주기 위해 당신의 명성이나 자유 시간을 위험에 빠뜨릴 것을 요구합니다.

상사의 관점에서 사물을 보려고 노력하십시오. 대체하려는 기능이 소프트웨어가 수행하는 핵심 기능인 것처럼 들립니다 (예 : "나사"설명). 훌륭한 관리자는 자신의 위험에 따라 핵심 비즈니스를 아웃소싱한다는 것을 알고 있습니다. 그는 앞으로 사라질지도 모르는 기술에 농장을 베팅하는 것에 대해 걱정하고 있습니다. 핵심 기능이 관련되면, Not Invented Here 실제로는 좋은 것입니다.

속도가 기능이라면 속도를 높일 수있는 다른 방법을 찾아야합니다. 그렇지 않으면, 고객보다 속도가 당신에게 더 중요하다면, 나는 그것을 포기하고 잊어 버린다고 말합니다.

“손상되지 않은 것을 고치지 말라”는 장점이 있지만, 나는 받아 들여진 대답에 동의하지 않습니다.

허용되는 답변은 문제가 해결되지 않았다는 관점에서 나옵니다. 중간 경영진의 관점에서 이것은 사실입니다. 즉시 사용 가능한 솔루션을 구입하는 것과 비교하여 개발자가 C #에서 ETL 솔루션을 만들고 유지 관리하는 데 소요되는 시간에 대한 비용 분석을 수행 한 경우 C # 솔루션을 만드는 데 3-4 배 더 오래 걸린다는 것을 보여줍니다 유지하고 비용을 10 배나 더 많이 듭니다 (숫자에 대한 참조를 찾았지만 찾을 수 없었습니다).

회사의 핵심 역량이 아니라면 C #에서 데이터 변환을 작성하고 유지해야 할 이유가 거의 없습니다. 자체 개발 한 솔루션은 느리고 실수 (예 : 데이터가 손상됨)가 발생하며, 엣지 사례가 발생하며, ETL 클래스간에 재사용이 거의 없으며, 취약합니다. 솔직히 개발자가 C #에서 ETL을 작성하고 유지 관리하는 데 시간을 보내고 싶은 것은 무엇입니까? 난 끝냈어. 쓰레기 야. 창조적 인 작업과는 거리가 멀다.

비즈니스가 ETL 인 회사 인 Informatica와 같은 도구를 사용하십시오. 그들은이 문제를 15 년 이상 일해 왔습니다. 그들은 해결했다. 도구는 드래그 앤 드롭으로 재사용 성이 내장되어 있으며 성능도 그대로 유지됩니다. 대부분의 사람 (예 : 개발자도 없음)은 Informatica 도구를 사용하여 ETL을 만들 수 있습니다. Informatica를 판매하려고하지 않고 도구를 사용하십시오. 바퀴를 다시 발명하지 마십시오.

장기적으로 Informatica와 같은 도구를 구입하거나 SSIS를 사용하면 회사가 장기적으로 수백만 달러를 절약 할 수 있습니다. 무엇보다도 ETL을 유지 관리하거나 중단 될 때 책임을지지 않아도됩니다.

전에 간단한 작업을 수행하기 위해 SSIS를 시도했습니다.

간단한 작업조차도 저수준에서 중간 수준의 복잡성 다이어그램을 낳기 때문에 매우 성 가실 수 있습니다. 그리고 내가 알지 못하는 Jim의 대답으로 지적한 소스 제어 문제 .

부작용 : 따라서 속도를 높이기 위해 이미지 대량의 트랜잭션 크기를 줄이는 것이 좋습니다. 5000 개가 아닌 800 개가 있다고 가정 해보십시오. 해당 트랜잭션을 지원하는 데 필요한 I / O 크기를 줄일 수 있습니다.