1. SQL vs NoSQL

• SQL은 일정한 형식을 가지고 데이터 베이스에 데이터를 저장하지만, NoSQL은 그 형식을 없애어서 더 자유롭게 자료를 저장할 수 있다는 것에 가장 큰 차이점을 가진다.
• 그렇다고 한쪽이 무조건 좋다 라고 할 수 없다. 상황에 따라 맞는 방법을 사용하게 된다.

2. 둘의 차이점

1. 수평적 확장성 vs 수직적 확장성 :
   • 수평적 확장성 => NoSQL: 서버의 갯수를 늘리면 무한대로 저장공간이 늘어날 수 있고, 응답의 속도도 크게 떨어지지 않는다. 그래서 큰 프로젝트를 할 때 더욱 어울린다. 물론 그만큼 사용되는 비용도 많이 늘어난다.
   • 수직적 확장성 => SQL: 하나의 노드에서 모든 것을 처리하게 된다. 그래서 계속 한 곳에 쌓인다고 표현하는 것 같다. 고성능의 장비 하나로 모든 것들을 처리하게 되기 때문에 비용은 적다. 하지만 처리속도에 그래도 무리가 간다.
2. 쿼리 언어의 유무
   • 기본적인 언어는 비슷하게 사용된다. 하지만 NoSQL같은 경우, Relation Data 즉, 다양한 행과 열로 이루어진 테이블들이 계속해서 JOIN 되어 조밀하게 연결되어 있는 경우, 정확한 틀이 없어서 유지보수를 하기 복잡해진다. 
3. 스키마의 유연성
   • 앞에서도 말 했듯이, 정확한 형태의 스키마를 이용해 데이터를 저장하게 되는 SQL과 더 자유롭게 스키마를 형성할 수 있는 NoSQL의 스키마의 유연성이 가장 큰 차이를 보인다.
   • 간단하게 말하면 NoSQL은 아무 JSON 문서도 다 데이터 베이스에 넣어버릴 수 있다. 모든 오브젝트 형식을 다 넣을 수 있기 때문이다. 이것이 자유다!

3. JSON vs BSON

• JSON형식은 우리가 알고 있는 그 형식이다. {}로 묶은 각각의 필드들이 문자열처럼 따옴표로 이루어져 있고, 그에 대한 값을 : 뒤에 적어주며, 쉼표로 각각의 필드들을 구분해 준다.

{
	"id": 1,
    "name": "Tom"
    "age": 22
}

• BSON은 JSON 처럼 텍스트 형태가 아니라 여러 가지 다양한 데이터 타입도 다 사용이 가능한 형식이다. JSON보다 읽는 속도가 빠르다. 하지만 JSON처럼 인간이 읽어서 내용을 파악하는 것은 무리가 있다.

{"hello": "world"} →
\x16\x00\x00\x00           // total document size
\x02                       // 0x02 = type String
hello\x00                  // field name
\x06\x00\x00\x00world\x00  // field value
\x00                       // 0x00 = type EOO ('end of object')

• MongoDB에서는 둘 다 데이터 베이스에 넣을 수 있다. 하지만 MongoDB 내부에서는 BSON 형식으로 사용 중이다.

4. MongoDB

• MongoDB는 NoSQL의 모델 중 하나이며, DOCUMET를 이용한 방식으로 데이터 베이스에 접근한다.
• mySQL처럼 비슷한 명령어들이 있으며, 몇 가지는 다르다.

5. MongoDB에서 주로 사용하는 명령어

• mongo : 인스턴스 활성화, 간단하게 시작할 때 사용한다고 생각하면 된다.
• use 데이터 베이스 이름 : 사용할 데이터 베이스를 결정한다.
• show dbs : 데이터 베이스의 목록을 본다.
• db.stats() : 데이터 베이스의 상태를 본다.
• db.shutdownServer() : 데이터 베이스를 끈다.
• db.logout() : 데이터 베이스에서 로그아웃 한다.
• db.createCollection(컬렉션 이름) : 컬렉션을 생성한다.
• db. 컬렉션 이름.insert({json형식의 데이터}): 컬렉션에 데이터를 넣는다. => 만약 컬렉션을 만들지 않았어도 상관없다. 없으면 만들어 넣는다!
• db. 컬렉션 이름.find(): 컬렉션을 확인한다.
• db. 컬렉션 이름.remove({json형식에 맞게 적은 삭제할 document의 내용})
• db.컬렉션 이름. drop():컬렉션을 지워버린다.

1. MVC?

• Model View Controller을 줄여서 말한 것이다.
• 어제의 글을 보면 마지막에 구조를 파악하는 것이 중요하다고 적었다.
• 그 구조에는 일정한 패턴이 있었다. 그것이 바로 MVC이다!
• 각각의 역할에 따라 파일들을 나누어 다른 역할을 하게 만든다.

2. 그림으로 보는 MVC

3. MVC의 구성요소

1. Model : 데이터 베이스와 정보를 교환해서 Controller에게 정보를 주거나 요청을 받는다. 위의 그림에서는 MySQL이라고 되어 있다. 바로 View와 데이터를 교환하지 않는다.
2. View : 사용자가 실제로 보는 화면을 구성한다. 무조건 Controller와 소통을 한다.
3. Controller : View에서 일어나는 요청들을 Model로 주기 전에 데이터를 가공하며, 마찬가지로 Model에서 받은 데이터를 가공해 브라우저와 소통하는 진정한 연결다리가 된다.

1. sql 파일의 스키마 적용

• 아직 mysql을 실행 하기 전이다 => mysql -u root -p < sql파일의 경로 -D 데이터 베이스 이름
• 물론, 상대 경로를 적절히 이용해도 된다.
• mysql을 실행 중이다 => source sql 파일의 경로
• 경로를 잘 못 찾겠다면 VS code의 왼쪽 파일 목록에서 sql 파일에 오른쪽 마우스를 누르면 Copy path(경로 복사)가 있다.

2. env 파일 설정

• env파일에는 mysql과 연결하기 위한 환경변수가 들어있다.
• DATABASE_SPRINT_PASSWORD=이전에 정한 mysql 비밀번호를 입력해서 파일을 저장해 둔다.
• 비밀번호의 앞, 뒤 어디든 따옴표는 필요 없다. 딱! 비밀번호만 적어줘라. 아니면 에러 난다!
• 당연히, 당신의 mysql 비밀번호를 모두에게 공개할 필요는 없다. github에 공유하기 전에 gitignore파일 안에 같이 레파지토리에 업로드하지 않을 파일들을 정해서 env 파일까지 같이 공유하는 경우를 막자.

3. js 파일에서 작성한 쿼리의 형태

• 대부분의 쿼리를 날리는 형태는 정해져 있다.

items: {
    get: (callback) => {
      const query = `SELECT * FROM items`;
      db.query(query, (err, result) => {
        callback(err, result);
      });
    },
  },

• 위와 같은 형태로 get 요청을 보낼 수 있다.
• 보다시피, items에 있는 모든 정보를 가지고 오게 될 것이다.
• 요청으로 받아오는 인자를 사용할 수 도 있다.
• 한번 쿼리를 전송한 후, 받은 결과를 이용해 다음 쿼리를 보내고, 이후 원하는 결과를 얻도록 연속해서 쿼리를 보낼 수 도 있다.

• post: (id, name, totalNum, callback) => {
        const query = `INSERT INTO average (name_id, totalNum) VALUES (?, ?)`;
        const params = [id, totalNum];
        database.query(query, params, (err, result) => {
          if (result) {
            const query = `INSERT INTO order_items (school_id, classes_id, student_quantity) VALUES ?`;
            const params = average.map((el) => [result.insertId, el.id, el.quantity]);
            db.query(query, [params], (err, result) => {
              callback(err, result);
            });
          }
        });
      },

• 위의 예시는 먼저 쿼리를 보내서 가져온 데이터를 다시 쿼리를 보낼때 사용한다.
• 'params'로 데이터를 한거번에 넣을 수 있다. '?' 부분에 params가 들어가게 되며, 형태는 INSERT INTO를 쓸 때처럼 똑같이 순서만 맞추어 주면 된다.
• 'result.insertId'로 지금의 post요청으로 삽입된 id를 가져올 수 있다.  나머지 형태는 이렇게 된다.

• {
    fieldCount: 필드의 갯수,
    affectedRows: 영향을 받고 있는 행,
    insertId: 삽입된 ID,
    serverStatus: 서버의 상태,
    warningCount: 경고의 수,
    message: 메시지,
    protocol41: (true or false)
    changedRows: 변경된 행
  }

4. 구조를 이해해 보자.

• 위의 파일은 '모델' 폴더 안에 있는 서버로 요청을 보내는 함수가 들어있는 파일이다.
• 이는 데이터 베이스 폴더 안의 연결부로 인해 전송됨을 알 수 있다.
• app.js 파일에서 전체적인 구조를 파악하는 것이 가장 기초이다. 최상단의 연결부로 모두 가보자.
•  그리고 config 파일은 각 데이터 베이스에 맞게 서버를 열어주고 있을 것이다.
• spec 에서 어떤 데이터가 어떤 요청으로 들어오게 되는지 확인이 가능하다. 잘 보면 모든 구조를 파악하기 쉽다.
• controllers 에서는 서버로 html 요청을 보내고 있다. 어떤 데이터를 어떤 서버 상태로 보내주는지 확인할 수 있다.
• 이렇게 글로만 보면 잘 이해가 되지 않는다. 직접 파일을 구해서 최상단의 참고로 하고 있는 경로들을 하나씩 들어가 보면서 어떤 역할을 하고 있는지 공부해 보자.

1. 문제의 발단.

• sql 명령어들은 공식처럼 크게 어렵지 않다. 형태를 외워 놓으면 쓰기 편하고, 잊어버린다고 해도 검색하면 다 나온다. 어떨 때 어떤 명령어를 쓰는지 어렴풋이 알고만 있으면 된다.
• 하지만 JOIN의 경우는 헷갈린다. 무엇이 어떻게 합쳐지는지 어떤 식으로 돌아가는지 어렴풋이라도 알기 위해서는 정리가 필요하다고 생각했다.

2. JOIN?

• 여러 개의 테이블들을 합쳐서 데이터를 검색할 때 사용할 수 있다.
• 각 테이블들은 같은 값을 가지는 '칼럼'을 각각 가지고 있어야 한다.

3. JOIN 명령어의 기본적인 형태

SELECT 가지고 올 테이블.컬럼1, 가지고 올 테이블. 칼럼 2... FROM 기준이 될 테이블 LEFT 혹은, RIGHT 혹은, FULL 혹은 INNER JOIN 비교할 테이블 ON 조건 1, 조건 2...

4. 그림으로 보는 JOIN의 종류

• 이 그림에 색칠된 부분을 우리는 얻게 된다.
• 예를 들어, INNER JOIN(위 그림에는 INNER가 빠져있다)을 사용할 때, 왼쪽의 테이블과 오른쪽의 테이블을 겹쳐 보았을 때, 둘 다 에게 공통으로 가지고 있는 값이 있는 부분만 검색할 수 있게 되는 것이다.

5. 예시로 보는 INNER JOIN

T1 :

T2 : 

SELECT T1.NAME, T2.SHIFT FROM T1 INNER JOIN T2 ON T1.SHIFT_S = T2.ID

결과 :