programing

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

topblog 2023. 5. 8. 21:47
반응형

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

.NET 개발자로서 코드를 작성하는 것보다 SSIS 패키지를 선호해야 하는 이유는 무엇입니까?현재 제가 근무하고 있는 프로덕션에는 수많은 패키지가 있습니다. 이 패키지들은 "쓰기"(아마도 그리기)와 유지보수 모두에 악몽입니다.각각의 패키지는 C#과 VB가 있는 다양한 색상의 스파게티 한 그릇처럼 보입니다.추상화가 중단되는 지점에서 NET 스크립트가 혼합되었습니다.각 "SQL 작업 실행" 또는 "Forach Loop"이 수행하는 작업을 확인하려면 저주받은 작업을 두 번 클릭하고 여러 탭에 흩어져 있는 리터럴 값과 식의 트리를 탐색해야 합니다.

저는 개방적인 마인드를 가지고 있기 때문에 SSIS가 단순히 코드를 작성하는 것보다 더 생산적이라고 생각하는 개발자가 있는지 알고 싶습니다.만약 SSIS가 더 생산적이라고 생각한다면, 이유를 말씀해주세요.

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

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

  1. 패키지를 단순한 SQL 작업 및 데이터 흐름 작업으로 유지합니다.
  2. 가능한 한 SSIS 외부(최대한 SQL)에서 작업합니다.
  3. 변수를 단일 전역 범위로 유지
  4. SQL을 인라인 상태로 유지하지 않고 변수 또는 저장 프로시저에 저장
  5. 구성 저장소(가능하면 SQL 데이터베이스)에 변수 값 유지

저는 SSIS를 여러 번 사용해 보았지만, 포기했습니다.IMO C#에서 필요한 모든 것을 수행하는 것이 훨씬 쉽습니다. SSIS는 너무 복잡하고, Gotchas가 너무 많고, 가치가 없습니다.SSIS를 배우는 데 같은 시간을 보내는 것보다 C# 스킬을 향상시키는 데 더 많은 시간을 보내는 것이 훨씬 더 좋습니다. 교육에 훨씬 더 많은 보상을 받을 수 있습니다.

또한 VS 솔루션에서 기능을 찾고 유지하는 것이 훨씬 쉽습니다.VS를 사용한 유닛 테스트는 간단합니다.Subversion에서 소스를 확인하고 로드 방법을 확인하기만 하면 됩니다.유닛 테스트 SSIS 패키지는 부드럽게 표현하기에 매우 중요합니다.

게다가 SSIS가 일부 행에 일부 열을 채우는 데 묵묵히 실패하고 예외를 제기하지 않고 건너뛰는 경우도 있었습니다.우리는 문제를 해결하고 무슨 일이 일어나고 있는지 파악하는 데 많은 시간을 보냈습니다.C#에서 대체 솔루션을 개발하는 데는 1시간도 걸리지 않았고, 2년 동안 아무 문제 없이 작동했습니다.

제 생각에 SSIS는 ETL 운영만을 위한 것이며 해당 범위를 벗어나는 논리를 포함해서는 안 됩니다.

저는 SSIS가 여러 소스의 데이터를 통합하고 결합할 수 있는 충분한 솔루션이라고 생각하는 프로젝트에서 일한 불행한 경험을 했습니다.유감스럽게도 처음에는 잘 작동했지만 나중에 요구 사항이 바뀌었고 우리는 (결국) 잘못된 도구라는 것입니다.

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

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

SSIS는 그 자리를 차지하고 있으며, 그 자리는 일반 프로그래밍이나 저장 프로시저의 대체물이 아닙니다.ETL 학교(Extract, Transform, Load)에서 왔으며, 여기서 강점이 있습니다.

이전 이름(DTS, 데이터 변환 서비스)과 새 이름(SSIS, SQL 서버 통합 서비스)은 모두 SQL 서버 데이터베이스를 더 큰 프로세스로 통합하도록 데이터를 조작하도록 설계된 서비스(또는 서비스 집합)임을 분명히 합니다.

데이터를 프로그래밍 방식으로 이동하려면 Rhino ETL을 확인해야 합니다.

CSV 파일에서 단위 테스트 데이터를 로드하는 것과 같은 개발과 관련된 단순한 데이터 작업에 SSIS가 좀 지나치게 관여되어 있기 때문에 저는 저만의 프레임워크인 Fluent ETL도 작업하고 있습니다.

SSIS는 프로그램이 아닙니다.SSIS에서는 많은 것들을 더 빨리 만들 수 있고, 관리자로서 매우 상세한 진행 상황과 오류 정보를 얻을 수 있습니다. SSIS가 해결해야 할 시나리오에서는 매우 유용할 수 있습니다. 왜냐하면 때때로 일이 잘못되고 관리자에게 많은 정보가 필요하기 때문입니다.

그렇긴 하지만, SSIS는 만약 당신이 자체적으로 설명할 수 있는 것들이 없다면 그렇게 유용하지 않습니다 - 그것들은 무언가를 위한 것입니다.

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

반응형