중앙 테이블에 모든 '물건'을 저장하는 단점

Question

설명 할 용어가 있는지 확실하지 않지만 콘텐츠 관리 시스템이 모든 종류의 데이터를 최소한의 속성으로 단일 테이블에 저장하는 것을 관찰했습니다 메타 데이터는 키 값 쌍의 형태로 다른 테이블에 저장됩니다.

예 : 모든 것 (블로그 게시물, 페이지, 이미지, 이벤트 등)은 하나의 테이블에 저장되고 게시물로 간주됩니다.

나는이 추상화 쉽게 확장 우리는 우리의 새로운 프로젝트를 이런 식으로 디자인 고려하고

수 있습니다 것을 이해합니다. 정확히 CMS는 아니지만 계속해서 모듈을 추가 할 계획입니다. 처음에는 댓글을 게시 할 수있는 게시물과 이미지 만 표시됩니다. 나중에 댓글 달기 기능이있는 동영상을 추가 할 수 있습니다.

이 접근법의 단점은 무엇입니까? 우리와 같은 요구 사항에 효과가 있을까요?

감사

Answer 1

단순성과 확장은 참으로 속성 값의 자주 매력적인 측면하며 접근 (당신이 말한대로) "사물의 단일 테이블".

여기에 100 % 오른쪽 대답은 없습니다 - 성능/처리량 목표 및 확장 성 요구 사항에 따라이 방법이 효과가있을 수 있습니다.

그러나 어떤 종류의 데이터를 저장할 지 알고있는 곳에서는 별개의 엔터티를 자체 테이블로 모델링하고 그에 따라 데이터를 관련시키는 것이 일반적입니다. RDBMS는 수십 년 동안이 유스 케이스를 수용하기 위해 설계되고 정제되었으며 일반적으로 테이블을 일반적인 덤핑 장으로 사용하는 것은 데이터를 적절하게 모델링해야한다는 불가피한 필요성을 지연시키는 행위를 제외하고는 일반적으로 별다른 이점을 얻지 못합니다. 또한 모든 것을 하나의 표로 끓일 경우 앱 작성자 (예 : 보고서 작성자 등)가 사용자의 '모델을 모델로 삼아'고민해야만 앱 외부에있는 사용자가 강제로 사용자를 괴롭힐 수 있습니다 쓰기 쿼리 등등. 그리고 당신은 가장 낮은 공통 분모에 가라 앉을 것입니다. 유형 X에 대한 쿼리를 최적화하고 동일한 테이블에 Y와 Z 유형이있는 경우 X 쿼리에 대한 성능에 영향을 미칩니다.

다시 한번 말하지만, "모든 것이 하나의 테이블"이라는 이름/값 스타일 메타 데이터 접근법에 명백한 이점이 있습니다. 나는 그 (것)들을 사용하고 유사한 이유를 위해 만들기에 대하여 돌았 다. 그러나 필자가 실제로해야 할 때 (즉, 필요한 공간을 올바르게 모델링하기 전에 뭔가를 구현해야하는 경우)에 자제하는 것이 좋습니다. 가장 일반적으로, 필자는 복잡한 시스템을 프로토 타이핑 할 때 그 일을 발견하고 나중에보다 빨리 뭔가를 얻을 필요가 있습니다.

Answer 2

단점은 주 테이블이 많은 수의 읽기 (충분한 쓰기 수)를 얻게된다는 것입니다.

이것은 잠금 경합을 많이, 무거운 인덱싱이있을 것을 의미 등

당신이 이렇게 메인하지 테이블의 일련의 "기본 테이블을"분할 고려할 수이 조금 완화하기 위해 .

말, 당신은 이미지에 대한 "게시물"(아마도 메타 데이터 또는 개인 스티커, 발표, Shoutbox, 같은 게시물의 특정 유형에 대한 서브 테이블을 통해 세련된 ...)

한 기본 테이블에 대해 하나 개의 기본 테이블이있을 것이다 (아마도 gif, jpeg 등을 위해 세련된CMS를 또는 포털 프레임 워크와 같은 '무한 tweakable "으로 무언가) 내가 이런 생각을 의도)

비디오에 대한 하나 개의 기본 테이블 ...

이 사용자 지정 응용 프로그램 인 경우 (그리고 분할이 허용 가능하며 더 많은 성능을 제공 할 수 있습니다 (많은 양의 데이터가 필요할 것으로 예상되는 경우).

"예"의견 ... 우선 모든 거대한 항목을 보관하는 것처럼 동일한 거대한 테이블에 다시 의견을 남기면 유사한 문제가 발생할 수 있습니다. 이것이 문제가 아니라고 가정하면, 주석을 원본 항목에 연결하는 일종의 참조 키 (당연히 일반적인 외래 키를 사용할 수 없음)를 넣을 수 있습니다.

이 항목은 항목을 주석으로 이동할 때 잘 작동합니다. 주석에서 시작 항목으로 이동해야 할 때가 적습니다. 따라서 귀하의 문제에 대해 어떤 종류의 작업이 더 자주 발생하는지에 대한 절충안이 있습니다.