SQL Server에서 XML 데이터 형식을 언제 사용해야합니까?

Microsoft SQL Server에서 언제 XML 데이터 형식을 사용해야합니까?

스토리지를 위해 객체 데이터를 XML로 직렬화하는 비슷한 작업을 수행했습니다. 따라서 복잡한 개체에 대한 데이터를 보유하기 위해 테이블, 열 및 관계를 갖추어야하는 부담이 없습니다. 결과 XML이 준수하는 스키마를 사용하여 프로세스를 수행 할 수 있으며 데이터베이스 테이블을 사용하여 해당 오브젝트에 대한 메타 정보를 사용할 수 있습니다. 필자의 경우 객체 레이아웃을 수용하도록 데이터베이스 스키마를 확장하는 것은 큰 작업이 될 것입니다!

개인적으로, 이전에는 SQL Server에서 XML 필드 유형을 사용한 적이 없으며이 기능을 추가 한 이후 많은 데이터베이스 프로그래밍을 수행했습니다. 데이터베이스에서 XML 콘텐츠를 기본적으로 사용하는 경우 프로그래밍 방식과 성능 오버 헤드가 항상있는 것 같습니다. 모든 사람들이 2000 년대 초 어느 시점에 XML 기차를 타고 있었기 때문에 나는 그것이 실제로는 특수 효과라고 생각했다. "오, XML은 뜨겁기 때문에 SQL Server에 추가하여 지나치지 않게 보자."

내가 볼 수있는 가장 좋은 비즈니스 사례는 구조와 데이터를 들여다보고 싶지만 비즈니스 또는 법적 이유로 원본 메시지의 무결성을 유지하려는 XML 기반 데이터 메시지를 기록하는 것일 수 있습니다. XML을 테이블 구조로 변환하기에는 오버 헤드가 너무 클 수 있지만 SQL Server에서 XML 기능을 사용하면이를 사용하기에 충분한 데이터 검사 비용을 줄일 수 있습니다.

당신이 그것을 사용하고 싶은 다른 수십 가지 이유가 있을지 모르지만 솔직히 말해서 SQL Server에서 XML을 사용하기 전에 다른 특별한 길을 고려해야한다고 생각합니다. 더 의미가 있으면 varchar (max) 또는 텍스트 필드를 사용하십시오.

물론 내 의견 :)

SQL Server에서 XML 데이터 형식을 적극적으로 사용하려는 몇 가지 시나리오 만 발생했습니다. 이것은 가장 흥미로운 것부터 순서대로 내 머리 꼭대기에 있습니다.

• 다른 응용 프로그램에서 생성 된 XML 응답 저장 / 보관
  • 예를 들어, 맞춤형 Silverlight 응용 프로그램과 Dynamics AX 간의 통신을 위해 AIF (Application Integration Framework)를 사용합니다. 인바운드 및 아웃 바운드 메시지를 데이터베이스에 저장하여 해당 애플리케이션 간의 통신 문제 해결을 지원합니다.
  • 필드 유형은 일반 문자열 유형 (예 : VARCHAR)이 아닌 XML이기 때문에 XQuery를 사용하여 특정 기준과 일치하는 메시지를 구체적으로 쿼리 할 수 ​​있습니다. 간단한 문자열처럼 일치하면 훨씬 어려울 것입니다.
• 구성된 응답 메시지 캐싱 / 지속
  • 계산 된 열을 모방하는 트리거 또는 응용 프로그램 코드로 XML 필드를 업데이트하십시오.
  • 호출 응용 프로그램 기반의 XML 응답을 지속적으로 재생성하는 대신 모든 호출이 아닌 행이 업스트림 될 때만 오버 헤드가 발생합니다.
  • 이것은 SELECT가 UPDATE / INSERT보다 훨씬 빈번한 경우에 가장 효과적이며, 대부분의 응용 프로그램에 해당되는 경향이 있습니다.
• 단일 필드에 여러 값 저장
  • 내가 본 사례 중 하나는 XML 데이터 형식을 사용하여 단일 필드에 값 모음을 저장하는 것입니다.
  • 간단한 키 / 값 저장소를 위해 추가 테이블 세트를 설계 할 필요가 없다는 이점이 있습니다
  • 이것의 단점은 데이터가 완전히 정규화되지 않아서 쿼리가 덜 명확하다는 것입니다
  • 그러나 위에서 언급 한 것처럼 해당 XML 필드에서 XQuery를 사용하여 식별 기준과 일치하는 행을 선택하여 완전히 정규화되지 않은 영향을 부분적으로 억제 할 수 있습니다.

99 %의 시간으로 스키마를 설계 할 때 XML 필드가 전혀 필요하지 않습니다.

몇 번이나 SQL 서버에서 XML 데이터 형식을 보았을 때 기본적으로 데이터베이스의 다른 쿼리와 마찬가지로 쿼리 된 필드로 사용되었으므로 많은 양의 데이터가 있으면 성능에 영향을 줄 수 있습니다 . XML 서버가 아닌 SQL 서버라고하는 이유가 있습니다. :-) XML에 반하는 쿼리는 일반적인 select 쿼리를 수행하는 것만 큼 빠르지 않습니다.

쿼리하지 않은 XML을 저장하는 데 사용되는 것을 볼 수 있습니다. XML 데이터 유형으로 전체 XML 문서를 저장하지만 검색 가능한 필드 (키)를 XML 문서와 별도로 저장하는 것과 같습니다. 이렇게하면 전체 문서를보고자하는 시점에 도달하면 정보를 더 빨리 쿼리하고 XML 문서를 가져올 수 있습니다. 실제로 돌아가서 사람들이 XML 데이터 유형을 많이 쿼리 된 필드로 사용하려고 시도하고 쿼리가 너무 느려진 지점으로 데이터를 성장시킨 수많은 앱 으로이 작업을 수행해야했습니다.

ASMX 웹 서비스 또는 WCF 서비스와 관련된 로깅 목적으로 주로 XML 유형 필드를 사용했습니다. 요청 또는 응답 메시지를 저장할 수 있습니다.

대부분의 경우, 일반적인 비즈니스 활동 (코드에서 5 초마다 쿼리하지 않음)이 아닌 참조 목적으로 XML을 DB에 저장합니다. 자신이 그렇게하는 경우 일반적으로 쿼리하거나 대부분의 시간을 사용하는 필드를 결정하고 별도의 열을 만듭니다. 이렇게하면 XML을 DB에 저장할 때 이러한 필드를 추출하여 해당 열에 저장할 수 있습니다. 나중에 이들을 검색하는 동안 XML 문서를 쿼리 할 필요가 없으며이 목적으로 작성한 열을 사용할 수 있습니다.

다음은 Sql Server에서 Xml 필드를 허용하기 위해 어떤 조건이 존재해야하는지 고려할 때 엄청나게 떠오르는 시나리오입니다.

• 리소스 제어와 같은 산을 원하는 교환을 위해 인코딩 된 이진 데이터
• 동적 정보를 사용하여 전체적으로 재구성 될 문서 조각
• 사용자가 격리하고 최소한 임시로 문서 나 조각을 제출하여 파일 시스템을 직접 차단하십시오.

데이터베이스에 대한 단일 호출로 구조화 된 데이터를 저장하기 위해 클라이언트-서버 앱에서 XML을 광범위하게 사용합니다. 예를 들어 세부 라인이있는 송장을 가져옵니다. 클라이언트가 비즈니스 오브젝트를 XML로 직렬화하고 단일 호출로 저장된 proc에 전달하도록하는 것은 간단합니다. proc은 삽입 또는 업데이트가 필요한지를 결정합니다. 서버 측 트랜잭션 내에서 그리고 클라이언트가 여러 번 왕복 할 필요없이 세부 레코드에 할당 할 상위 송장 ID (ID 열)를 얻을 수 있습니다. 헤더 레코드를 지정하기 위해 20 개 정도의 매개 변수가 필요하지 않으며 모든 송장 라인을 호출 할 필요가 없습니다. 또한 클라이언트를 건드리지 않고도 스키마를 변경하거나 로깅 / 감사를 도입 할 수 있습니다.