수평 데이터베이스 및 수직 데이터베이스

Question

Gedcom을 준수하는 가계도가있는 소셜 네트워킹 사이트에서 작업하고 있습니다. 사용자 프로파일에 수평 또는 수직 데이터베이스 구조를 사용해야하는지 결정해야합니다. 따라서 수평 데이터베이스 구조를 언제 사용 해야하는지, 수직 데이터베이스 구조를 사용하는시기에 대답 할 수 있는지 알고 싶습니다.

필드가 결정되지 않은 쇼핑 사이트에 대한 답변을 발견했습니다. 수직 데이터베이스 구조를 사용해야합니다. 그러나 나는 가계도 사이트에 무엇을 사용할 것인지 혼란스러워합니다. 수직 또는 수평을 사용해야합니까?

Answer 1

Storage 용 MySQL, MS SQL, SQLite, PostgreSQL 또는 Oracle과 같은 관계형 데이터베이스를 사용한다고 가정합니다.

GEDCOM은 정보 교환의 표준이므로 몇 개의 열을 알 수 있습니다. 아마도 표준은 향후 새로운 속성으로 확장되었지만 아마도 많은 새로운 속성이 아닐 수도 있습니다. 몇 개의 새 열로 테이블을 쉽게 확장 할 수 있습니다.

나는 엔티티-아트리 바이트-값 시스템 (세로 테이블)이 아닌 '수평'테이블을 사용합니다. 수직 테이블 시스템은 느린 경향이 있습니다. 제대로 인덱싱하고 쿼리 최적화기를 혼동 할 수 없습니다.

사용자가 Eye Colo (U) r 또는 좋아하는 colo (u) r과 같은 프로파일에서 새로운 속성을 정의 할 수있을 때 다른 이야기가됩니다. 그 프로필이 얼마나 유연하기를 원하십니까?

Answer 2

수직 데이터베이스는 Detawarehousing 및 Read/Only Reporting에 적합합니다. 일반적으로 당신은 밤새 재생합니다. 그들의 쓰기 성능은 일반적으로 매우 나쁘지만 Select는 10-100 배 더 빠릅니다.

수직 데이터베이스를 사용하기위한 일반적인 시나리오는 (매일) 스냅 샷을 생성 한 다음 쿼리를 실행할 때 OLAP보고입니다. 대부분의 혜택은 비교적 적은 수의 필드 만 요청하는 쿼리에서 비롯됩니다. 예를 들어 넓고 큰 테이블에서 소수의 필드 만 선택할 때. 수백만 레코드에 대한 이러한 쿼리 쿼리 (예 : Sum/Count/AVG 계산)는 1-2 초만 소요됩니다.

귀하의 사례는 수직 데이터베이스의 좋은 후보가 아닌 것 같습니다.

Answer 3

Tuinstoel에 동의합니다. 수직 테이블/EAV 시스템은 느리게뿐만 아니라 시간이 매우 복잡합니다. 때로는 테이블을 다루는 일부 API 방법을 작성해야하며 개발자는 복잡성을 피하기 위해 이러한 방법 만 처리해야합니다.

따라서 더 많은 필드를 추가 할 필요가 없다면 수평 테이블을 유지하십시오. 그러나 다국어 기능을 지원하려는 경우 다른 테이블이 필요할 수 있습니다. 그러나 나는 여전히 수평 테이블을 고수하는 것이 좋습니다.

또한 사용자 프로필과 관련된 사이트를 개발하고 있으며 수평 테이블을 사용하고 있으며 향후 다른 언어 지원이 필요한 경우 언어가 중요한 필드에 대해서만 수정합니다.