SQL Server XML 및 웹 응용 프로그램 아키텍처

아티클
08/07/2008

John A. Bocharov

Microsoft Developer Network

요약 : 이 기사에서는 Duwamish Books, 4단계 응용 프로그램 및 더욱 강력해진 Duwamish 온라인 응용 프로그램이 SQL Server XML 기반 솔루션 집합에 적용되었을 때 만들어지는 아키텍처 개요를 설명합니다(12페이지/인쇄 페이지 기준).

소개

Microsoft SQL Server 2000은 SQL Server XML이라는 새로운 XML 기술 계열에서 새로운 기능의 선두 주자로 시장을 석권했습니다. 이러한 기술 제품군은 향상된 기술과 새로운 기능을 바탕으로 SQL Server를 웹에 더욱 친숙한 응용 프로그램으로 만들고 Microsoft .NET 비전에 한 걸음 다가설 수 있도록 합니다.

SQL Server XML은 웹 응용 프로그램 아키텍처를 확장, 향상 및 교체하는 데 사용할 수 있습니다. 새로운 기능은 다음과 같은 두 가지 주요 구성 요소로 구분할 수 있습니다.

데이터베이스 구성 요소. 데이터베이스에서 XML을 읽고 처리하고 쓸 수 있도록 합니다.
SQL Server XML 인터넷 서버 API(ISAPI) 응용 프로그램. HTTP를 통해 데이터베이스에 액세스할 수 있도록 합니다.

이러한 구성 요소 중 하나 또는 둘 다를 사용하여 아키텍처상 흥미로운 몇 가지 가능성을 제시하게 됩니다. 새 도구의 성능과 유연성을 테스트하기 위해 우리는 이미 입증된 Duwamish 온라인의 논리적 아키텍처를 선택하여 SQL Server XML 기반 솔루션 집합에 적용시켰습니다. 연구에 완벽을 기하기 위해 좀 더 단순한 Duwamish Books, 4단계 응용 프로그램과 좀 더 강력한 Duwamish 온라인 응용 프로그램을 모두 테스트에 사용했습니다. 이렇게 해서 만들어진 아키텍처 개요는 다음과 같습니다.

논리적 아키텍처

응용 프로그램에 관계 없이, 응용 프로그램 인수화를 가능하게 하는 구성 개념인 "논리적 아키텍처"와 응용 프로그램 구현 방법을 나타내는 물리적 아키텍처 등 두 개의 아키텍처가 항상 연구 대상이 된다는 점을 염두에 두어야 합니다. 드물지만 간혹 이 두 아키텍처를 정확하게 구분해야 하는 경우가 있으므로 이러한 구분이 필요합니다. 곧 알게 되겠지만 특정한 논리적 디자인에 적합한 물리적 아키텍처는 상황에 따라 변하게 됩니다.

Duwamish 온라인 및 그 후속 버전을 만들면서 우리는 Microsoft n 계층 지침에 기반하는 논리적 아키텍처를 결정했습니다. 이 아키텍처는 웹 응용 프로그램에 의해 수행되는 일반적인 작업으로 구성되며 Duwamish 온라인에 한정된 것이 아닙니다.

그림 1. 논리적 아키텍처

응용 프로그램은 다섯 개의 논리 계층으로 구분됩니다. 클라이언트로부터 가장 먼 위치에 데이터 계층이 있으며 응용 프로그램이 필요로 하는 정보를 저장합니다. 바로 위에 데이터 액세스 계층이 있고 이는 데이터를 데이터베이스 내부 표현 방식으로부터 추상화하고 모든 데이터베이스 작업에 공통되는 루틴을 포함합니다. 데이터 액세스 계층은 업무 논리 계층에서 직접 사용합니다. 업무 논리 계층은 상위 계층으로부터 트랜잭션 세부 구현 내용 및 논리를 숨김으로써 업무 트랜잭션을 추상화합니다. 아키텍처에서 바로 다음 단계는 워크플로 계층입니다. 이것은 업무 외형을 의미하며 표시 계층에 facade로 알려진 간단한 인터페이스를 제공합니다. 내부적으로 워크플로 계층은 상태를 관리하고 업무 논리 계층에서 제공하는 원자 연산을 통해 복잡한 워크플로를 완성합니다. 마지막 단계에는 표시 계층이 있으며 워크플로 계층에서 반환한 결과 값을 사용자가 볼 수 있도록 변환합니다. 이 변환 작업은 XSL 스타일시트를 적용하여 결과를 HTML로 변환시키는 것처럼 간단할 수도 있고 또는 전화선에서 결과를 읽어들이는 음성 알고리즘처럼 복잡할 수도 있습니다.

이제 이러한 논리 아키텍처로부터 파생된 몇 가지 물리적 아키텍처를 살펴보겠습니다.

물리적 아키텍처

로드 분산

SQL Server XML을 사용하면 데이터베이스에서 단순히 데이터를 읽고 쓰는 것 이상의 일을 할 수 있습니다. XML은 저장 프로시저로 하여금 고도로 구조화된 다량의 데이터 처리를 가능하게 합니다. 관련 정보는 XML을 통해 저장 프로시저로 보내지고, 이 때 XML은 COM+ 또는 스크립트가 아닌 저장 프로시저로서 업무 논리 또는 워크플로 구현을 가능하게 합니다. 이것은 이제 사용자가 더 많은 응용 프로그램 처리를 데이터베이스 계층으로 이동시킬 수 있다는 것을 뜻합니다. 이 방법을 택할 경우 데이터베이스는 응용 프로그램에서 최소의 확장 가능 부분임을 명심하십시오.

데이터베이스와 웹 서버 사이에서 응용 프로그램이 수행해야 할 처리를 분산시키는 방법을 결정하는 것은 중요합니다. 이러한 결정은 응용 프로그램이 필요로 하는 하드웨어와 소프트웨어에 영향을 끼치며 응용 프로그램을 개발하는 데 필요한 기술 종류 및 응용 프로그램을 배포하고 업데이트하며 유지하는 절차에 영향을 끼칠 것입니다. 단순화를 목적으로, 웹 서버가 대부분의 작업을 수행하는 서버 구성을 "top-heavy"라 하고, 반대로 데이터베이스 서버가 대부분의 작업을 수행하는 서버 구성을 "bottom-heavy"라 명명하겠습니다.

다음과 같은 두 가지 요소로 인해 "top-heavy" 서버 그룹이 대부분의 응용 프로그램 모델로 선택됩니다.

비용. 데이터베이스 서버의 소프트웨어와 하드웨어는 웹 서버의 소프트웨어와 하드웨어보다 비용이 비쌉니다.
확장성. SQL Server 2000의 데이터베이스 확장성은 SQL Server 7.0에 비해 향상되었지만 새로운 하드웨어의 모든 성능을 충분히 사용하기 위해서는 세심한 계획과 효과적인 유지 관리 계획이 필요합니다.

이러한 이유로 "bottom-heavy" 서버 구성에 기반한 아키텍처에 대한 논란이 여전히 남아 있습니다.

Microsoft n 계층의 물리적 아키텍처

비교를 위해 SQL Server XML을 사용하지 않는 Duwamish 온라인(http://www.duwamishonline.com/(영문 사이트))의 물리적 아키텍처를 살펴보겠습니다. Duwamish 온라인은 방금 설명한 논리적 아키텍처를 최대한 구현하도록 설계되었습니다. 각 계층이 각기 한 종류의 논리적 작업을 수행하도록 되어 있지만, 그 범위 이상의 기능 분산이 일어납니다. 예를 들어, 어떤 업무 논리는 성능 향상을 위해 데이터베이스의 저장 프로시저에 의해 실행됩니다. Duwamish Books, 4단계에 익숙한 독자들은 아키텍처가 거의 변경되지 않았음을 곧바로 깨닫게 될 것입니다.

그림 2. Microsoft n 계층 아키텍처

이 아키텍처는 작업에 가장 적합한 기술을 사용하여 각각의 구성 요소가 특정 작업 유형에 전문화될 수 있도록 합니다. 예를 들어, 캐시는 최대 성능을 위해 C++로 작성되고 표시 논리는 Active Server Pages (ASP) 및 XSL을 사용하여 처리되고 워크플로, 업무 논리 및 데이터 액세스는 Microsoft Visual Basic®에 의해 수행됩니다. 또한 구성 요소 및 데이터베이스 작업은 Transact SQL(T-SQL)에서 처리됩니다. 기술 범주로 구분되지 않은 계층은 COM+ 구성 요소별 구현으로 구분됩니다. 이러한 유연성에 대한 대가는 다양한 계층이 함께 작동할 수 있어야 한다는 것입니다. 교차 환경 디버깅은 쉬운 작업이 아니며 특정 환경에서 안전한 데이터를 대상 환경에 맞게 다시 서식 지정하는 데 주의가 필요합니다. 예를 들어, 문자열 "a < b"는 데이터베이스에는 어렵지 않게 저장이 되지만 이스케이프시키지 않고 XML 파일에 적용하면 대괄호 불일치가 발생하여 파서를 엉망으로 만듭니다.

읽기 측면의 물리적 아키텍처

Duwamish 온라인은 응용 프로그램 전반에 걸쳐 단일의 물리적 아키텍처를 사용합니다. 반대로 SQL Server XML 버전은 읽기와 쓰기에 대해 서로 다른 두 개의 보완적인 물리적 아키텍처를 사용합니다. 지금 같은 경우에는 두 가지 사용 사례가 각각 다른 처리 방법을 필요로 하기 때문에 후자가 적합합니다.

참고 https://msdn.microsoft.com/voices/news/sqlxml.asp(영문 사이트)의 전체 아키텍처 다이어그램을 참조하십시오.

그림 3. 읽기 측면 아키텍처

SQL Server XML 기술은 최대 성능을 위해 데이터베이스 계층에서 표시 계층에 이르기까지 모든 계층에서 사용됩니다. SQL Server XML ISAPI 응용 프로그램은 웹 계층 ASP를 대치합니다. ISAPI 응용 프로그램 및 SQLOLEDB 공급자는 코드 크기와 개발 시간을 감소시켜 데이터 액세스를 자동화합니다. 이러한 성능을 달성할 경우 ASP의 견고한 개체 모델에 손실을 입고 이로 인해 유연성도 떨어지게 됩니다.

이제부터는 더욱 미묘한 아키텍처의 기능에 대해 살펴보겠습니다. 표시 계층은 이제 XSL 스타일시트에 의해 독점적으로 처리됩니다. 데이터베이스로부터 반환된 데이터는 XML이기 때문에 많은 이해가 될 것이고 XSL을 사용하면 기술 독립적이라는 이점을 추가로 얻을 수 있습니다. 즉 템플릿, ASP 페이지 및 COM+ 구성 요소에서 동일한 스타일시트를 만들 수 있습니다. 템플릿은 워크플로 계층을 구성합니다. 템플릿은 XML 명령 파일이며, 데이터 추상화와 데이터 보안 수준을 제공하는 동시에 HTTP를 통해 데이터베이스에 빠르게 액세스할 수 있도록 하여 데이터 구동 방식의 동적인 웹 페이지를 생성합니다. 템플릿은 주로 저장 프로시저를 사용하여 데이터에 액세스하지만 XDR(XML Data Reduced) 스키마를 사용할 수도 있습니다. XDR 스키마는 데이터베이스 개체를 XML 요소에 매핑하는 직관적인 구문 및 XPath(XML Path Language) 사용 기능을 제공합니다.

응용 프로그램에서 읽기 전용 작업은 데이터 액세스 루틴에 쉽게 통합되는 최소량의 업무 논리를 가지고 있기 때문에 이 아키텍처에는 별도의 업무 논리 계층이 없습니다. 이러한 응용 프로그램이 아닌 경우에 업무 논리 계층은 데이터베이스에서 저장 프로시저 집합으로 효과적으로 구현될 수 있습니다.

가장 많이 달라진 부분은 단연코 데이터베이스 계층이라고 할 수 있습니다. 새로운 기능 집합을 통해 저장 프로시저가 XML을 직접 읽고 쓸 수 있게 되었습니다. 사실 모든 데이터 검색은 XML 통해 이루어집니다.

쓰기 측면의 물리적 아키텍처

SQL Server XML 템플릿은 고도로 간소화되어 가능한 한 효율적으로 HTTP를 통해 데이터베이스에 액세스할 수 있도록 합니다. 이것을 실행하기 위해서는 기능 집합을 어느 정도 제한해야 합니다. 템플릿에서 찾을 수 없는 기능을 요구하는 경우에는, SQL Server 소유 ISAPI 응용 프로그램은 ASP, ASP와 COM+의 조합 또는 사용자 지정 ISAPI 응용 프로그램으로 대치됩니다.

이 섹션에서 설명하는 아키텍처는 사용자 페이지가 다음과 같은 사항을 실행해야 할 경우에 적합합니다.

다중 서버의 데이터베이스를 액세스하는 경우
설계 시점에서는 알려지지 않은 서식을 갖는 HTTP 요청을 처리하는 경우
COM/COM+ 개체를 호출하는 경우
COM+ 트랜잭션을 사용하는 경우
지불 공급자와 같은 응용 프로그램 또는 인터넷 웹 서비스에 연결하는 경우

그림 4. 쓰기 측면 아키텍처

웹 계층 코드는 데이터 액세스, 업무 논리, 워크플로 및 표시 계층 등 네 계층의 응용 프로그램 기능을 나타냅니다. 응용 프로그램을 개발할 때는 아키텍처에 맞춰 이 코드를 요소화하십시오. 이렇게 하면 사용자 코드의 가독성을 높일 수 있으며 결과적으로 유지 관리가 용이해 집니다. ASP만을 독점적으로 사용하는 경우에 스크립트 클래스는 매우 효율적입니다. 업무 논리 또는 워크플로 계층에서 많은 양의 복잡한 처리를 해야 하는 경우, COM+ 구성 요소를 사용하면 속도가 훨씬 더 빨라집니다. 반대로 처리할 양이 적을 때는 스크립트를 사용하는 것이 더 빠를 수 있습니다.

이 아키텍처를 새롭고 흥미롭게 하는 것은, 데이터 계층에서부터 표시 계층에 이르기까지 모든 계층이 XML을 사용하여 정보를 전송하고 저장한다는 것입니다. 데이터베이스의 저장 프로시저는 새로운 기능을 사용하여 XML을 읽고 씁니다. 데이터 액세스 계층은 데이터베이스와의 효율적인 XML 기반 통신을 위해 ADO 2.6 스트림을 사용합니다.

더욱 새로운 방법은 중간 계층의 일부를 데이터베이스 계층쪽으로 이동시키는 것입니다.

데이터베이스 중심 아키텍처

Duwamish 온라인 아키텍처는 데이터베이스가 확장성이 가장 떨어지는 부분이기 때문에 여기에 대해서는 가능한 한 적은 작업을 수행한다는 가정을 기반으로 합니다. 배포 분할 보기와 같은 새로운 기능은, 데이터베이스의 확장성을 증진시키고 개발자에게 작업 대부분을 어디에서 수행할 것인가에 대한 선택 기회를 주면서 작업 부하를 다중 서버에서 공유할 수 있도록 합니다.

SQL Server XML 아키텍처와 함께 "bottom-heavy" 서버 그룹(데이터베이스 측면에 치중)을 사용하기로 선택했다면 다른 대안은 n 계층 구성 요소의 계층화와 유사한 방식으로 데이터베이스의 저장 프로시저를 계층화하는 것입니다. 이렇게 하는 경우, 적합한 데이터 구조를 선택하고 가능한 한 중복 코드를 피하는 것과 같은 좋은 프로그래밍 습관이 요구됩니다.

그림 5. 데이터베이스 중심 아키텍처

이 아키텍처의 표시 계층은 데이터베이스의 저장 프로시저에 액세스하기 위한 코드도 포함합니다. 이 코드는 일반적인 데이터 액세스 계층에서 볼 수 있는 코드와 동일합니다. 그러나 이러한 루틴은 워크플로 계층에서 제공한 부분을 호출하기 때문에 이 부분을 데이터 액세스 계층이라 부르는 것은 오해의 소지가 있습니다.

저장 프로시저를 사용하여 개발할 때 주의해야 할 함정이 있습니다. 먼저 계층에 공통되는 작업을 실행한 뒤 다음 단계를 진행하려면 어떤 코드 경로를 따를 것인가를 결정하는 전환 논리를 수행하는 지능적인 저장 프로시저를 사용하는 디자인을 먼저 고려해 봅시다. 워크플로 계층에서의 "지능적인 프로시저" 호출은 몇 가지 다른 작업 중 하나에 해당합니다. 이런 프로시저는 다음과 같을 수 있습니다.

CREATE PROCEDURE 
/* 워크플로 작업을 수행하는 지능적인 프로시저입니다. */
DoWorkflow
   /* Action는 이 호출에 가능한 몇 가지 작업 중 하나를 선택하는 데 사용합니다. */
   @Action nvarchar(255),
/* SomeOtherParameters는 워크플로에서 사용할 수 있는 다른 입력에 대한 자리 표시자입니다. */
   @SomeOtherParameters ntext
AS
/* 워크플로에 공통적인 작업을 수행합니다. */
Execute SomeCommonWorkflowOperations
If @Action = N'Action1'
BEGIN
      /* Action 1 수행 */
   Execute BusinessLogicAction1
END
Else If @Action = N'Action2'
BEGIN
      /* Action 2 수행 */
   Execute BusinessLogicAction2
END
GO

처음으로 프로시저가 호출될 때, SQL Server는 가장 먼저 실행할 코드 경로에 대한 실행을 최적화합니다. 비록 더 비용이 많이 들거나 또는 더 빈번히 사용된다 할지라도 남은 코드 경로는 더 비효율적으로 실행됩니다.

모든 코드 경로가 최상의 실행을 하고 있는지 확인하려면 각 작업에 별도의 프로시저를 만들고 가능한 모든 전환 논리를 피합니다. 코드 중복을 막으려면 어떤 계층에서 여러 작업이 공유하는 기능은 별개의 프로시저에 두어야 합니다. 이렇게 설계하면 많은 수의 프로시저가 생기게 되지만 최적화 측면에서 본다면 응용 프로그램의 효율성이 향상됩니다.

통합

웹 개발에 있어 뛰어난 점은 구현의 세부 사항이 사용자로부터 숨겨진다는 것입니다. 따라서 이 기사에서 설명한 아키텍처는 탁월한 사용자 환경을 통해 단일 응용 프로그램에 쉽게 결합될 수 있습니다. 다음은 사용자 응용 프로그램의 다른 부분을 쉽게 통합할 수 있도록 하는 몇 가지 지침입니다.

응용 프로그램에서 XML 사용. XML은 모든 기술에 전반적으로 사용되며 XSL 스타일시트를 사용하여 쉽게 변환되고 어디에나 어려움 없이 저장될 수 있습니다. SQL Server XML을 사용하면 응용 프로그램에서 더욱 쉽게 XML을 사용할 수 있습니다.
가능한 모든 코드를 요소화.
- XSL 스타일시트를 사용하여 XML을 변환합니다. 동일 XSL 스타일시트는 템플릿, COM+ 구성 요소 및 스크립트 간에 쉽게 공유할 수 있습니다.
- 사용자 스크립트로 여러 기능을 수행하는 경우 스크립트 클래스를 사용하여 코드를 요소화합니다.
- 데이터베이스쪽에서는 데이터 액세스에 항상 저장된 프로시저를 사용합니다. 저장 프로시저는 유지 관리하기도 쉬울 뿐 아니라 컴파일되지 않은 SQL 쿼리보다 훨씬 빨리 실행됩니다.

영향

이 섹션에서는 새로운 아키텍처를 사용하는 것이 사용자 응용 프로그램의 기능 및 성능에 어떠한 영향을 미치는지에 대해 설명합니다.

프로그램 가능성

프로그램 가능성은 응용 프로그램 코드화의 용이성을 말합니다. 이것은 종종 기능 집합과 비교할 때 응용 프로그램을 개발하는 시간으로 적용됩니다. 그 예로 Duwamish 온라인 응용 프로그램을 들 수 있습니다. 응용 프로그램의 다섯 계층은 완전히 다른 기술 집합을 기반으로 만들어집니다. 표시 계층은 캐시 구성 요소에 대해 C++를 사용하고 XML, XSL 및 ASP와 같은 웹 기술도 사용합니다. 워크플로, 업무 논리 및 데이터 액세스 계층은 Visual Basic COM+ 구성 요소이며, 데이터베이스의 저장 프로시저는 T-SQL로 작성됩니다. 많은 기술을 사용하면 개발자는 각 작업에 최상의 기술을 선택할 수 있다는 장점이 있습니다. 그러나 이 모든 구성 요소가 효과적이고 효율적으로 작동될 수 있도록 하는 것은 상당히 어려운 작업입니다. 구성 요소가 각기 다른 프로그래밍 언어를 사용하여 여러 다른 도구에서 개발되는 경우 구성 요소 간 추적 및 디버깅은 더욱 어려워집니다.

사용자 응용 프로그램에서 SQL Server XML을 사용하면 본질적으로 다른 기술로 작업하는 경우에 발생되는 문제점을 최소화할 수 있습니다(XSL은 여기서 제외됩니다. XSL은 SQL Server XML에 속해 있지는 않지만 SQL Server XML 템플릿에 쉽게 통합됩니다). 계층은 마찰을 최소화하여 함께 작동합니다. 모든 중간 데이터가 XML이기 때문에 계층 간의 디버깅은 더욱 쉬워지며 어떤 컴파일도 수반되지 않습니다. 그러나 프로그램 가능성의 가장 큰 장점은 코드 크기를 대폭 줄일 수 있다는 것입니다. Duwamish Books, 4단계의 SQL Server XML 버전은 원래 코드 크기의 1/10 정도에 해당하는 COM+ 버전과 동일한 결과를 가집니다. 이 결과는 데이터 액세스, XML 변환, XSL 변환 및 데이터 캐싱에 대한 SQL Server XML의 기본 제공 기능에 의해 촉진됩니다.

그럼에도 불구하고 XSL을 위한 효과적 디버깅 도구가 없고, 특히 Microsoft Visual Studio®에서 제공한 상호 언어 디버깅 기능을 비교해 볼 때, 다른 새로운 기술을 위한 디버깅 도구가 상대적으로 미비하기 때문에 이러한 장점이 다소 줄어듭니다.

관리 효율

SQL Server XML 응용 프로그램은 쉽게 배포할 수 있습니다. 웹 계층에서 실행되는 코드인 경우 파일은 간단히 대상 디렉터리에 복사되고 구성 유틸리티가 한 번 실행되면 적합한 가상 디렉터리를 설정할 수 있습니다. 오래된 파일을 교체하기만 하면 업데이트가 수행됩니다. SQL Server Enterprise Manager를 사용하면 데이터베이스 개체를 쉽게 관리할 수 있습니다.

성능

사용 권장 사항

모든 새로운 기술에 대한 가장 중요한 질문은 언제 사용할 것인가에 대한 것입니다. SQL Server XML이 모든 인터넷 문제에 대한 궁극적인 해결책은 아니지만 코드 크기 및 개발 시간의 대폭 감소, 성능 향상, 유지 관리의 용이성 등 몇몇 시나리오에서는 상당히 유용합니다. 다음에 요약되어 있듯이 이 새 기술의 두 가지 주요 구성 요소인 데이터베이스와 ISAPI 응용 프로그램은 다른 사용 시나리오를 가지고 있습니다.

SQL Server XML 데이터베이스 서버 구성 요소는 거의 모든 응용 프로그램에서 사용됩니다. 데이터베이스에서 XML을 사용하도록 기존 응용 프로그램을 변환하는 작업도 유용하며 다음과 같은 장점이 있습니다.

지역화를 쉽게 함(XSL 사용)
플랫폼 및 기술 독립적
XML 데이터의 캐싱을 쉽게 함
오프라인/연결이 끊긴 응용 프로그램 사용 기능
웹 서비스의 포함 또는 생성을 쉽게 함
다른 응용 프로그램과의 상호 운용성

새로운 기술의 웹 인터페이스 구성 요소는 더욱 전문화되어 있습니다. 이 구성 요소는 데이터베이스에 빠르고 효율적으로 액세스할 수 있으며 XSL 스타일시트를 통해 데이터 구동 방식의 페이지를 쉽게 만드는 기능을 제공합니다. 이러한 장점은 사소한 것이 아닙니다. 테스트에서 보면 캐시가 없는 Duwamish 온라인 SQL Server XML 카탈로그 검색이 캐시가 있는 Duwamish 온라인보다 15% 정도 성능이 뛰어납니다. 앞서 SQL Server 2000의 기술 미리보기 버전에서 행했던 실험을 보면 SQL Server XML ISAPI 캐시가 성능을 상당히 향상시킬 수 있다는 것을 알 수 있습니다. 하지만 사용자 응용 프로그램이 다음과 같은 것을 포함하고 있는 경우 ASP 중간 계층 사용을 고려해야 합니다.

"데이터 추상화와 무관한 광범위한 업무 논리 루틴". 이러한 루틴을 어디에 둘지에 대한 두 개의 옵션이 있으며 데이터베이스 내의 저장 프로시저에 두거나 XSL 내의 스크립트에 둘 수 있습니다. 스크립트는 효율성 측면이 불확실하고 구조적 쿼리 언어(SQL) 또한 이러한 루틴에 대한 최적의 언어는 아닙니다.
"특히 결과 집합에 대한 광범위한 문자열 조작". 데이터베이스에 저장된 문자열을 XML 또는 HTML을 위해 이스케이프 처리하는 것은 예외입니다. SQL Server 2000의 새로운 기능에 의해 이 작업은 자동으로 실행됩니다. 자세한 정보는 SQL Server 온라인 설명서(XML 및 인터넷 지원\ XML 데이터 검색 및 쓰기 \ FOR XML을 사용한 XML 설명서 검색 \ EXPLICIT 모드 사용 \ F. cdata 지시문 지정)를 참조하십시오.
"많은 양의 HTML 입력". 템플릿 제한으로 인해 설계 시점에서 서식이 알려진 HTTP 요청으로부터 일부 정보를 검색할 수 없습니다. ASP 페이지를 사용하는 경우에는 문제 없이 완료됩니다.

주의! SQL Server 2000은 URL을 통하여 데이터베이스에 직접 액세스할 수 있도록 합니다. 이 기능은 무엇보다도 동적인 템플릿을 허용하게 되므로 아키텍처가 가지고 있는 많은 문제를 해결하는 데 도움이 됩니다. 그러나 이 기능을 사용하면 데이터베이스를 삭제하는 쿼리도 실행되도록 하므로 이 기능을 사용하는 경우에는 데이터베이스 보안이 완벽한지 확인해야 합니다.

결론

SQL Server XML은 데이터베이스로부터 직접 XML을 검색할 수 있게 허용하여 사용자 응용 프로그램 종단 간에 XML을 사용하는 새로운 자극제가 되었습니다. 새로운 ISAPI 응용 프로그램의 성능은 뛰어나지만 사용자 응용 프로그램의 일부 사용 사례에는 적합하지 않을 수 있습니다.

최종수정일: 2001년 1월 8일