DBMS

버퍼에 SELECT 쿼리문을 넣고 flush를 한다. 그럼 br이 받음

[ HeidiSQL이란? ]

원격 접속 툴. MariaDB 데이터베이스에 접속하기 위해 사용
HeidiSQL을 사용하여 MariaDB에 접속하기 위해서는 'IP 주소, 포트 및 프로토콜'을 입력

[ select 쿼리문 ]

SELECT 쿼리문은 데이터베이스에서 데이터를 조회할 때 사용한다. 

쿼리문을 클라이언트에서 데이터베이스 서버로 전송할 때, 보통 버퍼에 담겨서 전송된다. 
데이터베이스 서버는 받은 쿼리문을 실행하여 해당 조건에 맞는 데이터를 찾고, 
그 결과를 테이블 형태로 구성하여 버퍼에 저장, 그 결과 테이블을 
테이블 형태로!! 클라이언트로 전송(반환)한다.

[ insert, update, delete 쿼리문 (애네는 write) ]

데이터 베이스 프로토콜 [ -1, 0, 1 등]

insert, update, delete 처럼 결과로 건네줄게 없으면 보통 숫자를 반환한다. 

한 번에 insert 쿼리를 3번 날리면, row가 3건이 생기겠지?
2건은 성공, 1건은 실패했다고 가정하자
그러면 DBMS가 숫자 2를 응답함 > 즉, 2개만 성공하고 1개가 안들어왔다는 것!
insert를 1건 요청 했을 때, 1을 반환 > 성공!

0을 반환하면, insert가 안됐다는 의미! (인서트가 안 됐다고해서 오류가 아님.)
DBS에 id = 1이 없는데. id가 1인걸 delete 요청하잖아? 
이건 오류가 아니다. 못 찾아서 삭제가 안 된 것 뿐! 그래서 0을 리턴!

진정한 오류는 -1
deeleete 뭐 이렇게 적으면 쿼리 자체(문법)가 틀린 것!
이런걸 쿼리문으로 날리면 -1을 던진다. 너 오류야! 틀렷어! 하고.

이런 식으로 뜨는 듯 하다. 

[ update 쿼리문은 많은 자원이 소모된다 ]

select 쿼리문은 요청할 때, select 쿼리문만 날리면 마리아db에서 결과를 응답해 준다.
insert도 똑같이 insert문만 날리면, 마리아db가 받아서 DBS에 쓸 것!

근데 update문은 수정하는 행위다. (수정 = select하고, delete하고, insert를 한다는 것!)
그래서 업데이트할때 많은 자원이 소모된다. 

0. 내가 a를 b로 변경한다는 update 쿼리문을 날리면
1. UPDATE 쿼리문에 해당하는 데이터를 찾기 위해 내부적으로 select가 일어남
   (수정할 데이터 검색)
2. 찾은 데이터(수정 할 데이터)를 메모리에 보관하여 수정 작업을 수행. 
   (수정 전 데이터를 유지하기 위해 필요)
3. DELETE 쿼리문을 내부적으로 실행하여 이전 데이터를 제거
4. INSERT 쿼리문을 사용하여 변경된 데이터 삽입

즉, 업데이트란 select delete insert문이 다 일어나는 것 = 자원소모 많음