내 경험상 두 가지 모두에 대해 생각할 사항이 거의 없습니다.

I. RDL 보고서는 일반적으로 HOSTED 보고서입니다. 즉, SSRS 서버를 구현해야합니다. 보고 언어에 대한 SQL Server의 Visual Studio 확장 기능이 기본 제공됩니다. SSRS를 설치할 때 ‘Business Intelligence Development Studio’라는 추가 기능이 있어야합니다.이 기능은 보고서없이 작업하는 것보다 훨씬 쉽게 작업 할 수 있습니다.

R eport

D의 efinition

L angauge

RDL 보고서의 이점 :

1. 서비스가 실행중인 환경에서 보고서를 호스팅 할 수 있습니다.
2. 독립 실행 형 개념으로 보안을 처리하도록 항목 또는 상속 수준에 대한 보안을 구성 할 수 있습니다.
3. 이메일을 발송하고 (접속할 수있는 SMTP 서버가있는 경우) 일정에 따라 파일을 저장하도록 서비스를 구성 할 수 있습니다.
4. 일반적으로 ‘ReportServer’라고하는 데이터베이스가 있으므로 게시 된 보고서에 대한 정보를 쿼리 할 수 ​​있습니다.
5. ASP.NET, WPF (winform 컨트롤 bleh! 포함)로 작성된 클라이언트 응용 프로그램의 ‘ReportViewer’또는 ‘ProcessingMode.Remote’를 사용하는 .NET의 Winforms를 통해 이러한 보고서에 액세스 할 수 있습니다.
6. 사용자가보고 사용할 수있는 매개 변수를 설정하여 더 많은 유연성을 얻을 수 있습니다.
7. 연결 문자열에 사용할 보고서의 일부를 ‘데이터 원본’으로 구성하고 SQL 쿼리, xml 또는 기타 데이터 집합을 ‘데이터 집합’으로 구성 할 수 있습니다. 이러한 부품 및 기타 부품은 정기적으로 데이터를 캐시하도록 저장 및 구성 할 수 있습니다.
8. http : // / ReportServer / ReportingService2010 또는 / ReportExecution2005 서비스의 .NET 프록시 클래스를 작성할 수 있습니다. 그런 다음 코드에서 SSRS 보고서를 호스팅하는 서버의 서비스에서 직접 SSRS 데이터를 이메일로 전송, 저장 또는 조작하기 위해 .NET에서 OWN 메서드를 구성 할 수 있습니다.
   ReportService2010.asmx를 사용하여 SharePoint에서 프로그래밍 방식으로 SSRS 보고서 내보내기

단점 :

1. SSRS는 다른 것들에 비해 빠른 속도로 작동하는 것과 비교할 때 일종의 경이 롭습니다. 대부분의 사람들은 보안 정책과 VS에 대한 ‘추가 기능’으로 보고서를 디자인하는 것에 혼란스러워합니다. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. 계속해서 1 보안 설정 IMHO에 대한 정책은 어리석게도 지나치게 복잡합니다. 서비스를 위해 호스팅되는 페이지에는 서버 보안, 데이터베이스 보안 및 역할, 두 가지 보안 설정이 있습니다. 대부분의 사람들은 들어갈 수없는 관리자 만 설정하고 다른 사용자가 할 수없는 이유를 궁금해합니다. SSRS에 대한 가장 일반적인 불만이나 질문은 일반적으로 내 경험에서 들어오는 것과 관련이 있습니다.
3. 보고서를 ‘향상’시키는 ‘표현식’을 사용할 수 있습니다. 종종 몇 가지 이상의 작업을 수행하고 보고서가 성능 크롤링으로 이동합니다.
4. 할 수 있고 내보낼 수있는 작업의 양이 정해져 있습니다. SSRS는 자바 스크립트 해킹없이 내가 아는보고 위에 마우스를 올려 놓지 않습니다.
5. 어리석은 SSRS 구성이 시스템을 재활용하고 첫 번째 보고서가 사이트를로드하는 데 시간이 걸릴 수 있으므로 속도와 성능이 타격을받을 수 있습니다. 이를 변경하여 해결할 수 있지만 연결 유지 서비스가 더 잘 작동하는 것으로 나타났습니다.

II. RDLC 보고서는 어디에도 호스팅되지 않는 클라이언트 포함 보고서입니다. 이름의 추가 c는 ‘클라이언트’를 의미합니다. 일반적으로 이것은 Visual Studio 클라이언트 응용 프로그램에서만 사용하기위한 RDL 언어의 확장입니다. ‘보고’항목을 추가하면 Visual Studio에 존재합니다.

RDLC 보고서의 이점 :

1. wcf 서비스를 훨씬 더 쉽게 데이터 셋에 연결할 수 있습니다.
2. 데이터 세트를 더 많이 제어 할 수 있으며 Entity 프레임 워크 개체 또는 ADO.NET으로 채워진 POCO 클래스와 테이블 자체를 직접 사용할 수 있습니다. 보고서에 바인딩하기 전에 최적화를 위해 데이터를 가져갈 수 있습니다.
3. 코드 뒤에서 직접 추가 기능을 사용하여 모양을 더 많이 사용자 지정할 수 있습니다.

단점 :

1. 매개 변수를 직접 처리해야하며 래퍼 메서드를 구현하여 다리 작업이 예상보다 조금 더 많고 불행하게도 도움이 될 수 있습니다.
2. 사용자는 원격 모드에 있지 않고 RLD 보고서에 액세스하지 않는 한 ‘ReportViewer’컨트롤에서 매개 변수를 볼 수 없습니다. 따라서 컨트롤 외부에 텍스트 상자, 드롭 다운, 라디오 버튼을 직접 만들어 전달할 필요가 있습니다. 이 추가 컨트롤을 좋아하는 사람들은 개인적으로 그렇지 않습니다.
3. 배포를 위해 보고서를 서비스하는 데 원하는 모든 작업은 직접 작성해야합니다. 이메일, 구독, 저장. 죄송합니다. .NET에서 빌드하거나 이미 위의 프록시를 구현해야 호스팅 된 보고서를 사용할 수 있습니다.

솔직히 나는 다른 목적으로 둘 다 좋아합니다. 분석가가 그래프, 차트, 드릴 다운 및 Excel로 내보내기를 항상 사용하고 조정하는 분석가에게 무언가를 전달하려면 RDL을 사용하고 SSRS 사이트에서 이메일 배포를 처리하는 모든 작업을 수행하도록합니다. 보고서 섹션이있는 애플리케이션을 원하고 애플리케이션이 규칙 및 거버넌스가있는 자체 모듈이라는 것을 알고 있다면 RDLC를 사용하고 매개 변수를 더 작게하고 사용자가 보고서 파트에 도달하기 전에 내린 결정에 따라 결정됩니다. 클라이언트가 사이트에 있고 일반적으로 시간 프레임이나 유형 만 선택하면됩니다. 따라서 일반적으로 복잡한 보고서는 RDL을 사용하고 간단한 것은 RDLC IMHO를 사용합니다.

도움이 되었기를 바랍니다.

---

답변