GEDCOM 규격 인 가계도가있는 소셜 네트워크 사이트에서 작업하고 있습니다. 사용자 프로필에 수평 또는 수직 데이터베이스 구조를 사용해야하는지 결정해야합니다. 그래서 저는 누군가가 수평 적 데이터베이스 구조를 사용할 때와 수직적 데이터베이스 구조를 언제 사용해야 하는지를 알고 싶습니다.가로형 데이터베이스 및 세로 형 데이터베이스
필드가 결정되지 않은 쇼핑 사이트에 대한 답변을 찾았습니다. 수직적 인 데이터베이스 구조를 사용해야합니다. 그러나 가계도 사이트에 무엇을 사용해야하는지 혼란 스럽습니다. 수직 또는 수평을 사용해야합니까?
Mysql, Ms sql, Sqlite, Postgresql 또는 Oracle과 같은 관계형 데이터베이스를 저장소로 사용한다고 가정합니다.
Gedcom은 정보 교환을위한 표준이므로 사용자가 보유 할 열의 수를 알 수 있습니다. 어쩌면 표준은 미래에 새로운 특성으로 확장 될 것이지만 아마도 많은 새로운 특성이 없을 것입니다. 몇 가지 새로운 컬럼으로 테이블을 쉽게 확장 할 수 있습니다.
엔티티 - 속성 - 값 시스템 (세로 테이블)이 아닌 '수평'테이블을 사용합니다. 수직 테이블 시스템은 느려지는 경향이 있습니다. 쿼리를 올바르게 인덱싱 할 수 없으며 쿼리 최적화 프로그램을 혼동합니다.
사용자가 eye colo (u) r 또는 favorite colo (u) r와 같은 프로필에서 새 속성을 정의 할 수있는 경우에는 다른 이야기가됩니다. 그 프로파일이 얼마나 유연할까요?
나는 tuinstoel, 수직 테이블/EAV 시스템에 동의뿐만 아니라 느린뿐만 아니라 시간이 매우 복잡합니다. 때로는 이러한 테이블을 처리하는 개발자 자신의 API 메소드를 작성해야하며 개발자는 복잡성을 피하기 위해 이러한 메소드 만 처리해야하는 경우가 있습니다.
필드를 더 추가 할 필요가없는 경우 가로형 테이블을 사용하십시오. 그러나 다국어 지원 기능을 지원하려면 다른 테이블이 필요할 수도 있습니다. 그러나 나는 여전히 수평 테이블을 고수 할 것을 권고한다.
사용자 프로필이 포함 된 사이트를 개발 중이며 가로 테이블을 사용하고 있으며 향후 다른 언어 지원이 필요할 경우 언어가 중요한 필드에 대해서만 수정합니다.
세로 형 데이터베이스는 정보 수집 및 읽기 전용보고에 적합합니다. 일반적으로 밤새 다시 생성합니다. 그들의 쓰기 성능은 대개 매우 좋지만 SELECT는 10-100 배 빠릅니다.
수직 데이터베이스를 사용하는 일반적인 시나리오는 데이터의 (일일) 스냅 샷을 생성 한 다음 쿼리를 실행할 때의 olap보고입니다. 대부분의 이점은 상대적으로 적은 수의 필드 만 요청하는 쿼리에서 비롯됩니다. 너비가 크고 큰 테이블에서 소수의 필드 만 선택하면됩니다. 수백만 개의 레코드 (예 : SUM/COUNT/AVG 계산)에 대한 이러한 검색어는 단 1-2 분이면 충분합니다.
귀하의 사례가 수직적 인 데이터베이스에 대한 좋은 후보로 보이지 않습니다.
SQL Server 2008을 사용하고 있으며 사용자가 새 속성을 추가 할 수 없습니다. – Radhi