#mongodb

위와 같이 미디어 타입으로 언급된 것은 다음과 같은 고민이 있기 때문이다. 미디어와 글을 같은 타입으로 볼 것인가 → 전통적인 CMS와 다르게 모든 글을 가지고 올 때 개별 사진을 같이 가지고 왔으면 좋겠다. 즉, 글이 주가되는 CMS가 아니라 사진이 주를 이루는 CMS. 미디어에 캡션을 얼마나 부착할 것인가 → 가령 한장의 사진이나 유투브 영상에 담긴 스토리에 대한 reference 결론적으로 미디어도 하나의 글(객체)이면 좋겠다. 아래와 같이 고쳐본다 아래와 같이 linkedDocument로 따로 관리한다. 왠만하면 마크다운을

MongoDB에서는 속성의 네이밍을 최대한 줄인다. (성능이슈) install MongoDB 기본 db path는 /usr/local/var/mongodb다. 꼭 설치하지 않아도 기본 쿼리 몇가지는 웹에서 날려볼 수 있다. 스키마가 없다. 그래서 하나의 collection(즉, 테이블) 안에 다양한 구조의 document(즉, 데이터)를 밀어넣을 수 있다. 데이터는 구조로 표시된다. 중첩구조가 가능하다 (value, dictionary, list…) EAV패턴은 짧게 정리하면 데이터 구조의 변화 없이 속성(attribute)을 확장

CMS에 저장되는 사진의 DB 모델링 백엔드에서 구현 할 때 인터페이스화 하는 것이 좋을것같음 → 백엔드가 어떤 형태(URL, 직접저장, 퍼블릭클라우드) 인지 몰라도 가져오는데 지장이 없게끔 (OCP) 사진, 동영상, 글, 기타 메테데이터를 관리할 방법은? ex) 사진의 형태여도 백엔드가 외부 URL이거나 직접 store된거거나.. 미디어 모델링 UUID 또는 ID 미디어 : 미디어 형태: 사진|동영상|글 ← 왠지 이걸 분기하는 과정에서 오버헤드가.. 미디어 URL (또는 Reference) 메타데이터 reference 사진 메타데