데이터베이스에 XML을 저장하는 것이 "좋지"않습니까?

Question

여러 소스에서 데이터베이스에 XML을 저장하는 것이 "나쁘다"는 말을 들었지만 그 이유에 대한 실제 설명을 보지 못했습니다. 사실입니까? 그것이 사실이라면 왜 설명 할 수 있습니까? 또한 데이터베이스에 XML을 저장하는 "좋은"사례가 무엇인지 말해 줄 수 있습니까?

Answer 1

전혀 나쁘지 않습니다. Microsoft SQL Server에는 XML 데이터 형식이 있습니다. XML을 저장하는 하나의 유스 케이스는 우리 자신을 발견 한 상황이다. 특정 테이블의 각 행에 대해 해당 행과 관련된 가변 개수의 속성을 저장해야했다. 그리고 이러한 속성의 수는 시간이 지남에 따라, 그리고 각 행마다 바뀔 수 있습니다. 우리는 이러한 속성과 값을 XML 형식으로 저장하는 것이 더 효율적이라는 것을 발견했습니다. 앞으로는 속성의 수를 조정할 때마다 스키마를 변경할 필요가 없습니다. XML 저장

Answer 2

아니요, 그렇지 않습니다. 아마도 (등 분석) 이유를 속도

사실 여러 데이터베이스가 이미 저장 XML 문서

Answer 3

나는 데이터베이스가 나쁜 것 저장하는 생각에 대한 데이터 유형이있다. 그러나 반 구조 모델에 적합하다는 좋은 사례가 있는데 여기에 나열된 장점 중 일부는 here입니다.

Answer 4

는, JSON, YAML, 쉼표로 구분 된 목록, 진 모양, 또는 데이터베이스에서 다른 아무것도 ... 자체을 나쁘지 않다.

그것은는 데이터베이스 (다른 데이터와 관련된 데이터를 저장)를 위해 무엇인지에 대한 이해의 부족을 표시와 함께 ... 등 data1라는 단일 컬럼 테이블, data2와 데이터베이스의 비전을 연상 할 수 각 테이블 행은 XML로 인코딩 된 관계형 데이터의 +5 MB 항목을 보유합니다.

한편

, 이러한 구조에 대해 만들어 질 수있는 많은 유효한 경우가있다 - 급변 구성 JSON 표현과 같이 구성된 두 열 테이블에 저장 될 수있다 :

dbo.good_table 
ApplicationID (bigint) 
Configuration (varchar(max)) 

이와 같은 상기 테이블 및 테이블의 차이 :

dbo.bad_table 
ApplicationID (bigint) 
ApplicationMembers(xml) 

는 bad_table가 ofttimes expens로 데이터베이스를 사용하는 동안 good_table는, 데이터 (구성)의 일부에 대한 신속한 접근을 가능하게된다는 것이다 ive (및 느린) 하드 디스크.

Answer 5

XML 자체는 일종의 저장 파일입니다. 데이터를 구조화하기위한 공통 메커니즘을 제공하기 때문에 데이터 전송에 가장 많이 사용됩니다. XML 파일을 읽고 쓸 수있는 고정 규칙이 있으며 누구나 XML 파일을 읽을 수 있습니다. 또한 다른 출력 형식에 대한 유효성 검사 및 변형은 비교적 쉽습니다 (xslt 사용). 그러나 XML은 데이터를 저장하는 가장 좋은 방법은 아닙니다. XML 파일을 읽는 데 시간이 많이 걸리고 비교적 많은 공간을 차지합니다. 데이터베이스에 구조화 된 방식으로 데이터를 저장하고 보고서, 웹 사이트 또는 다른 당사자에게 전달해야하는 경우 특정 쿼리의 데이터를 XML로 내보내는 것이 가장 좋습니다.

XML 데이터베이스가 있지만 XML에도 데이터가 저장되지 않습니다. 표준 테이블 구조 대신 계층 적 데이터를 저장하고로드하는 방법을 제공합니다 (XML은 계층 적 구조 임).

데이터베이스의 BLOB에 XML 컨텐트를 저장하는 것이 일반적으로 올바른 방법이 아니라고 말하는 것은 당연합니다.하지만 항상 예외가 있습니다.

XML은 다른 사람들이 말하는 것과는 달리 - 데이터를 표시하는 방식이 아닙니다. 데이터를 내보내고 가져 오는 방법입니다. 데이터 전송을위한 논리적 인 선택입니다. 그것은 당신이 수출하고자하는 방식에 완전히 융통성이 있기 때문에 다른 형식으로 쉽게 변형 될 수 있기 때문입니다. 마찬가지로 웹샵이 있고 다른 업체에 가격과 제품 정보를 내보내려면 XML을 선택할 수 있습니다. 이러한 다른 당사자는이 데이터를 필요에 맞게 쉽게 변환하는 규칙을 작성할 수 있습니다. 어느 쪽도 가격이 다른쪽에 저장되는 방법을 알지 못합니다. 어느 쪽도 다른 사람이 작성한 일부 읽기 어려운 바이너리를 구문 분석하기 위해 복잡한 도구를 작성하지 않아야합니다.

Answer 6

여기 정말 바보 같은 답이있다 - 데이타베이스 가 지원하는 데이터 타입이 하지 당신이 그것을 사용해야 의미합니까해서. 경쟁이 그것들을 가지고 있기 때문에 이러한 것들은 언제나 기능으로 추가됩니다. 왜냐하면 그것들은 옳은 일이기 때문이 아닙니다. 전역 변수? 방아쇠? 당신이 그들을 사용할 수 있고 거기에 있기 때문에 누구도 그들을 방어하고 싶습니까?

여러 특성이있는 경우 관계형 데이터베이스에서 특성을 처리하는 가장 좋은 방법은 일대 다 관계입니다. XML 오버 헤드에서 유용한 데이터를 파싱합니다. 그런 다음 두 번째 테이블에 저장된 각 행이있는 상위 레코드의 ID (기본 키)를 속성 당 하나의 행에 저장하면됩니다. 상위 레코드 당 여러 개의 속성을 가질 수 있습니다. 그것은 데이터베이스 디자인 101이며 영리한 것은 아닙니다. 다양한 속성을 저장하기 위해 XML을 구조화되지 않은 XML로 저장하는 것은 이 아니고가는 길입니다. 땅콩을 깨는 것은 큰 허물입니다. 두 테이블 간의 일대 다 관계가 더 간단하고 이해하기 쉽습니다. 많은 쿼리가 가능하고 노력이 덜 필요하며 스토리지가 적습니다 (빠른 쿼리를 의미 함). 스토리지 공급 업체는 제외하고 모두 승리합니다.

XML은 데이터 전송 프로토콜입니다. GolezTrol은 "데이터를 내보내는 (그리고 가져 오는) 방법"이라고 말했습니다. 즉, 서로 다른 시스템간에 데이터 구조의 통신을 용이하게하는 데 사용되는 오버 헤드 일뿐입니다. 받은 태그는 데이터베이스 엔진에 저장된 데이터 (및 데이터 만)가 무엇이든간에 제거해야합니다. XML 자체가 아닙니다. XML에 대한 오버 헤드는 설명하는 데이터의 10 배입니다. 사장님 께 왜 100GB의 데이터가 고가의 SAN에서 1TB의 공간을 차지하고 있는지 알려주십시오. 또는 포화 된 네트워크 링크를 통해 밤새도록 백업 할 수 있습니까? 또는 프로덕션 환경에서 성능 문제가 발생합니까? 현재 무의미한 태그의 데이터를 분석하지 않으면 문제와 지속적인 일일 지원 비용을 향후 10 년간의 운영 지원에 투입하게됩니다. 조잡하고, 조잡하고, 조잡합니다. 따라서 EMC와 같은 공급 업체는 비즈니스를 유지할 수 있습니다.

XML은 메타 데이터입니다. 아무것도 영리하지 않고 단지 스키마 설명자입니다. 일단 전송되고 파싱되면 유용성을 잃어 버리고 사용하는 데이터베이스가 무엇이든 막히게됩니다. 어제의 무의미한 설명 메타 데이터에 중독 된 경우가 아니라면 여러 번 저장하십시오. 일어나. 그것은 전형적인 "Emperor 's New Clothes"증후군으로, 단순하고 일회용으로 끝나는 것을 그만 두었습니다. 그것은 단지 메타 데이터이고 저장되거나 숭배되어서는 안되며 일단 파싱되면 정크가됩니다. 그리고 더 나은 무엇입니까? 그것을 한 번, 또는 구문 분석 쓸모없이 그것을 시간에서 데이터가 필요합니까 구문 분석? 그 대답은 나에게 분명했다.