programing

프로그래머는 SSIS를 사용해야하며, 그렇다면 그 이유는 무엇입니까?

nasanasas 2020. 8. 30. 08:42
반응형

프로그래머는 SSIS를 사용해야하며, 그렇다면 그 이유는 무엇입니까? [닫은]


.NET 개발자로서 코드 작성보다 SSIS 패키지를 선호해야하는 이유는 무엇입니까? 우리는이 곳은 내가 현재 작업 생산에 패키지를, 그들은 모두 "쓰기"(아마도? 그릴) 및 유지 보수에 대한 악몽입니다. 각 패키지는 추상화가 중단되는 지점에서 C # 및 VB.NET 스크립트가 혼합 된 여러 가지 색상의 스파게티 그릇처럼 보입니다. 각 "SQL 실행 태스크"또는 "Foreach 루프"가 수행하는 작업을 파악하려면 저주받은 것을 두 번 클릭하고 여러 탭에 흩어져있는 리터럴 값 및 표현식 트리를 탐색해야합니다.

저는 개방적이므로 다른 훌륭한 개발자 가 단순히 코드를 작성하는 것보다 SSIS가 더 생산적 이라고 생각하는지 알고 싶습니다 . SSIS의 생산성이 더 높다면 이유를 알려주세요.


저는 매일 SSIS를 사용하여 대규모 데이터웨어 하우스와 큐브를 유지 관리합니다. 저는 2 년 동안 100 % 비즈니스 인텔리전스 및 데이터웨어 하우징이었습니다. 그 전에는 10을위한 .NET 애플리케이션 개발자였습니다.

SSIS의 가치는 일부 제한된 변환 및 조건부 분기를 통해 데이터를 한 지점에서 다른 지점으로 이동하는 워크 플로 엔진으로서의 것입니다. 패키지에 스크립트가 많이 포함되어있는 경우 팀은 잘못된 작업에 SSIS를 사용하고 있거나 SQL에 익숙하지 않거나 과대 광고를 한 것입니다. SSIS 패키지는 디버그하기가 매우 어렵습니다. 스크립트 구성 요소는 절대적으로 악몽이며 서식 지정, 반복 또는 최후의 수단으로 만 사용해야합니다.

  1. 패키지를 단순하고 SQL 작업과 데이터 흐름 작업으로 유지합니다.
  2. SSIS 외부, 가급적 SQL에서 최대한 많은 작업 수행
  3. 단일 전역 범위에 변수 유지
  4. SQL을 변수 또는 저장 프로 시저에 보관하고 인라인이 아님
  5. 구성 저장소 (가급적이면 SQL 데이터베이스)에 변수 값 유지

나는 SSIS를 여러 번 사용해 보았지만 포기했습니다. IMO는 C #에서 필요한 모든 작업을 수행하는 것이 훨씬 쉽습니다. SSIS는 너무 복잡하고 문제가 너무 많으며 그만한 가치가 없습니다. SSIS를 배우는 데 같은 시간을 보내는 것보다 C # 기술 향상에 더 많은 시간을 보내는 것이 훨씬 낫습니다. 교육에 대해 훨씬 더 많은 수익을 얻을 수 있습니다.

또한 VS 솔루션에서 기능을 찾고 유지하는 것이 훨씬 쉽습니다. VS를 사용한 단위 테스트는 쉽습니다. 내가해야 할 일은 Subversion에서 소스를 확인하고 어떻게로드되었는지 확인하는 것입니다. 단위 테스트 SSIS 패키지는 가볍게두기 위해 매우 복잡합니다.

게다가 SSIS가 일부 행의 일부 열을 자동으로 채우지 못하고 예외를 발생시키지 않고 건너 뛰는 상황이있었습니다. 우리는 문제를 해결하고 무슨 일이 일어나고 있는지 파악하는 데 많은 시간을 보냈습니다. C #으로 대체 솔루션을 개발하는 데 1 시간도 걸리지 않았으며 2 년 동안 아무런 문제없이 작동합니다.


제 생각에는 SSIS는 ETL 작업 전용이며 해당 범위 밖의 논리를 포함해서는 안됩니다.


저는 SSIS가 여러 소스의 데이터를 집계하고 결합하기에 충분한 솔루션이 될 것이라고 생각하는 프로젝트에서 작업 한 불행한 경험을했습니다. 안타깝게도 처음에는 잘 작동했지만 요구 사항이 변경되어 결국 잘못된 도구라는 것을 깨달았습니다.

아마도 우리는 그것을 잘못 사용하고 있었지만 우리가 스키마를 변경 한 적이 있다면 많은 어려움을 겪었고 결국에는이를 위해 C #에서 사용자 지정 도구를 작성하기 위해 프런트 엔드에서 ORM 정의를 재사용했습니다. 우리는 이미 데이터 모델을 가지고 있었기 때문에 이것은 놀랍도록 쉬웠습니다. 분명히 YMMV이고 나는 결코 SSIS 전문가는 아니지만,이 경우 SSIS는 소매를 감고 '핸드 코딩'할 때 많은 중복 작업과 두통을 일으켰습니다. 예상보다 쉬웠습니다.

그래서 SSIS를 고려할 때 유연성에 대해 많이 생각합니다.


SSIS가 그 자리를 차지하고 있으며 그 자리는 일반 프로그래밍이나 저장 프로 시저의 대체물이 아닙니다. ETL 학교 (추출, 변환 및로드)에서 제공되며 이것이 바로 강도입니다.

이전 이름 ​​(DTS, Data Transformation Services)과 새 이름 (SSIS, Sql Server Integration Services)은 모두 SQL Server 데이터베이스를 더 큰 프로세스에 통합하기 위해 데이터를 조작하도록 설계된 서비스 (또는 서비스 집합)임을 분명히합니다.


프로그래밍 방식으로 데이터를 이동하려는 경우 Rhino ETL을 살펴볼 수 있습니다.

또한 CSV 파일에서 단위 테스트 데이터를로드하는 것과 같은 개발과 관련된 간단한 데이터 작업에 SSIS가 너무 관련되어 있다는 것을 알게 되었기 때문에 자체 프레임 워크 인 Fluent ETL 에서도 작업하고 있습니다.


SSIS는 프로그램이 아닙니다. SSIS에서 많은 작업을 수행하는 것이 더 빠르며 관리자로서 매우 훌륭한 세부 진행률 및 오류 정보를 얻을 수 있습니다. SSIS가 해결하려는 시나리오에서 매우 유용 할 수 있습니다. 왜냐하면 때로는 일이 잘못되고 관리자가 많은 작업을 필요로하기 때문입니다. 정보.

즉, SSIS는 자신이 edxplanatory를 가지고 있지 않다면 실제로 유용하지 않습니다. 그들은 무언가를위한 것이므로 일반 프로그래밍에 너무 많이 들어가면 짜증이납니다.

참고 URL : https://stackoverflow.com/questions/3558185/should-programmers-use-ssis-and-if-so-why

반응형