링크 (https://velopert.com/436)의 강의를 참고하여 학습 및 실습한 내용을 정리하였습니다.
(Ex) Document내의 데이터 1개 구조 == "RDBMS의 Table내 데이터 하나의 행이라고 생각하면 쉽다."
{
"_id": ObjectId("5099803df3f4948bd2f98382"),
"username": "velog",
"name": { first: "J.H", last: "Park" }
}
--> _id, username, name 은 key이다.
--> 콜론(:) 오른쪽 값들은 value이다.
_id는 12bytes의 hexadecimal 값
각 document의 유일성을 제공
첫 4bytes는 현재 timestamp + 다음 3bytes는 machine id + 다음 2bytes는 MongoDB 서버의 프로세스 id + 마지막 3bytes는 순차번호(추가될 때 마다 값이 높아짐)
Document는 동적(dynamic)의 schema를 가지고 있다. 같은 Collection내의 Document끼리 다른 schema를 가지고 있을 수 있다. 즉, 서로 다른 데이터(서로 다른 key)를 가질 수 있다. --> RDBMS에서는 테이블의 schema가 고정되어 있어 같은 테이블 내의 데이터의 구조(schema)가 다를 수 없음.
schema가 없다. --> Collection내의 데이터 구조(=Document의 구조)가 다를 수 있다.
각 객체의 구조가 뚜렷하다.
복잡한 연산인 JOIN 연산이 없다.
Deep Query Ability : 문서지향적 Query를 사용할 수 있어 SQL만큼 강력한 Query 성능을 제공한다.
Application에서 사용되는 객체를 DB에 추가할 때 Conversion, Mapping이 필요X
https://docs.mongodb.com/v3.2/reference/operator/query/ --> 더 많은 MongoDB 연산자를 학습할 수 있습니다.
update() : 데이터의 구조 변경X + 값만 변경
replace() : 데이터의 구조와 값을 변경
(Ex)
name : "Betty" / age : 20 / city : Redmond
의 구조인 Document를 수정해보자
name : "Betty" / age : 30 / city : Redmond
데이터의 구조(틀)은 유지된 채 age의 값만 변경된다!
replace() --> name : "Betty" / age : 30
데이터의 구조가 변경된다. Document의 city가 없어졌으며 age는 30으로 변경되었다.
("연산자 및 함수와 옵션(매개변수)가 너무 많아 따로 정리하지는 못했다. 필요할 때 마다 공식문서를 참고하면 될 것 같다...") ("SQL과 문법이 달라 많이 헷갈렸다...")
The way you have presented your fnf game ideas in this opinion is both articulate and eloquent.