틈틈히 시간이 조금이라도 나면.. 블로깅 해야겠다.. 프로젝트하랴 바쁘지만..
배웠던건 블로깅 다 해놓아야겠다..
데이터베이스는 백엔드 개발의 꽃! 여러사람들이 공유하고 또 사용할 목적으로
관리되는 정보들의 집합이다.
이전에 스프린트진행이나 혼자 연습겸 리액트로 작업했을때, 데이터를 저장하려면
파일을 사용하거나, 인메모리 형태를 사용했었다.
file i/o는 나쁘진않은데.. 매번 파일을 읽어온다는 단점이 있었고, 데이터의 양이
많아지고 복잡해질수록 점점 쓰기가 힘들어진다는 단점도 있었다.
하지만 데이터베이스를 사용하면 테이블형태로 저장이 가능하고 sql문(새로운 언어지만
몇개만 알면 된다!!)을 사용해서 데이터값을 가져오기가 훨씬 편하다..!
sql문은 MySQL, Oracle, SQLite, PostgreSQL등 다양한 데이터베이스쪽에서도
볼 수 있는데 mysql이 가장 대중적인것 같아서 이걸 가르쳐준것 같다.
ACID 성질
계좌이체를 예로 생각해보자.(트랜젝션)
내가 친구의 계좌에 10만원을 넣어준다고 가정하자.
내 계좌에서는 -10만원일거고 친구 계좌는 +10만원이 되야 정상이다. 만약 내 계좌에서는 돈이 빠져나갔는데
친구의 계좌에는 아무런 변동이 없다면?? 돈은 어디로갔는가... 내돈...
이런 안정성을 보장하는 성질이 바로 ACID다.
Atomicity
원자성
하나의 트랜젝션에서는 모든과정이 성공하거나 모두 실패해야만한다!
예로들면, 위 과정에서 친구의 계좌에 돈이 안들어오면 응답으로 실패를 주어서 롤백을 시켜줘야한다.
Consistency
일관성
은행에 가서 예금을 하려고하는데 예로들어서 반드시 고객명과 주민등록번호를 줘야만 예금이 된다고하자. 그런데, 은행측에서 갑자기 주민등록번호를 뺀 예금을 요청한다?? 다른 고객들과 일관성이 없기때문에 이러면 안된다.
데이터베이스로 예를들면 어떤 특정데이터값에만 예외처리를 두면 이것이
데이터베이스 전체에 상태를 일반적이지않게 유지를 한다고하면 트랜젝션
처리가 안되게 하는것이다.
Isolation
고립성
내 계좌에서 b라는 계좌와 c라는 계좌에 각각 5000원씩 이체한다고 하면,
각각의 트랜젝션은 독립적으로 본다는것이다.
그러니까 각각의 트랜젝션 즉 b계좌와 c계좌는 서로 독립적인 상황
이걸 생각하면 된다.
Durability
내구성, 지속성
성공된 트랜젝션에 대해서 로그가 기록되고 영구적으로 남아야한다.
내가 b의 계좌로 1000만원을 이체했을때 갑작스럽게 은행서버쪽에서 에러가
난다면, 이체한 기록은 영구적으로 유지를 시켜줘야한다. 이게 바로 지속성이다.! 기록전에 에러가 났다면 이체내역이 실패로 돌아가고 이전 계좌상태를 유지해줘야한다.
