Relational Database

• 관계형 모델( 구현상의 문제)

AUtoIncrement가 존재 primary key로 디비에서 자동으로 다음값을 알고 id를 pk로 날린다.

mysql이 오라클로 넘어감(반 오픈소스 진영) 그리고 mysql진영에서 mariadb만듬

관계형 모델 내부에 데이터를 해오가 열로 이뤄진 테이블로 정의 codd의 규칙 13가지는 안지키지만 2가지는 무조건 지킨다.

쿼리를 통해 row를 받아오는 행위를 하고 여기서 행에 무엇이 들어가는지 테이블로 돌려받고 저장하는 행위.

row는 실제 들어가 있는 값.

pk라는 constraint를 줌으로서 돌려받는 게 pk. id값을 주는 부수적인 아이디값이 몇번쨰 들어갔는지 자동으로 증가하는 key가 있다(surrogate key) 이유는 더 간단하기 떄문.

Foriegn key는 잘 알고 사용 못하면 디비 조작할 때 힘들다 디비에선 constraint를 통해서 제약사항 하는데 이거 할 때 주의해야 한다.

Foreign key constraint를 빡세게 넣을 필요는 없다.

pk fk, foregin key 이런거 jpa가 다 해줘서 생각을 덜 수 있게 해준다.

ddl auto는 무슨 값으로 할까? 이런식으로 하게 된다.

DBA는 요즘은 좀 마이너 하다.

-d는 컨테이너 실행하고 d 옵션이 없으면 컨테이너 내부에 자신의 쉘 프로세서가 붙으면서 쉘 터미널을 유지했을 때만 컨테이너 살아 있게 된다.

프로세서 생성을 하게 하는 거. 자기 자신은 프로세서에서 떨어져 나온다. -e는 환경 변수 -d옵션이 없으면 터미널에 붙어있는 상태로 남아있는 상태가 됨.

마지막은 이미지 번호와 태그번호.(8버전 최신번호로 받음)

logs도 컨테이너에서 로그를 돌려주는 명령어 중 하나.

inspect는 어떤상태로 띄워졌는지

docker rm -f mysql는 컨테이너를 지우는 명령어

접속을 하기엔 어려움. mysql 서버 접근하기 위해 3306 포트가 열려있어야 하는데 아직 안 열려있어서 넣기 어렵다.

docker run —name mysql-stub -e MYSQL_ROOT_PASSWORD=1234 -p 3306:3306 -d mysql:8

이걸 다 외워서 쓰기엔 어렵지만 정확하게 뭘 써야 하는지 알고 쓰면 외우기 싫어도 외워진다.

데이터 무결성

• 데이터 무결성이라는 거 때문에 고통을 받는다. 여러 사람이 동시에 요청 날리면 문제가 생긴다.

도커도 일종에는 가상 os가 컴퓨터에 떠있다.

도커 엔진을 통해서 가상 os가 올라가서 어플리케이션이 실행된다.

그 안에서도 파일 작성하고 만들고 읽고 쓰고가 가능하다.

컨테이너가 떴으면 물리적으로 자동으로 할당이 되긴 함. 도커 내부 설정 디렉터리 안에 다른 디렉터리가 따로 존재한다.

컨테이너가 생명주기가 동일하다. 컨테이너 삭제하면 db의 내용도 다 날아가게 된다.

-v 옵션이 추가로 들어가야 한다. 컨테이너에서 사용할 디비에 어느 디렉터리에 들어갈 지.

도커 compose 도 유용한 도구

도커를 사용하기 위해 편하게 한다.

docker compose는 명령어로 전달할 내용을 저장하고 실행한다. 파일을 입력받아서 안에 정의된 내용을 한번에 올려준다.

v옵션이 volumes에 들어간다.

컨테이너 내부에 내부 디렉터리로 들어간다. volume 옵션의 의의

컨태이너 내부에 쓰는걸 해당 폴더로 쓰도록 만들어주는 옵션

컨테이너를 지워버린다. 해도 디렉터리에 남아있음. 똑같은 기준으로 실행해도 유지가 된다. 도커로 이미지 띄울떄 주의해야한다(v(volume)옵션 으로 )

Mysql Setting

• Root 계정으로 접속한다.

• 실제로 권장을 하는 건 root로 돌아가면서 쓰는걸 권장하지 않는다.

스키마 =- 조작하기 위한 테이블들이 다 모여있다.

connect는 디비에 접속 dba는 자기 이름 하에 있는 테이블을 만들 수 있다. 오라클은 auto commit이 꺼밋이 꺼져있다.(깃 커밋과 동일 한거) insert문 하나 날리면 바로 커밋 반영되야 하는데 오라클은 꺼져서 commit 명령어로 일일히 넣어줘야 한다.

새로운 유저 만들면 확인하고 오라클은 롤 자체를 만들 수 있따. (역할 군 만들어서 알 수 있따.)

create database demo_school;
create user 'staff' identified by 'password';

grant insert,
delete,
create,
drop,
select,
update on demo_school.* to staff;

템플릿에서 쿼리 실행하기 위한 도구. mysql 스크립트는 그런식으로 작동하지 않는다. 테이블을 생성하면서 프라이머리 키를 자동으로 생성해준다.

ER Diagrams

지식영역 하에(도메인)

이 사이트가 편하다 코드를 쓰면 그림으로 바로 표현이 된다.

기본적으로 db가 필요한 작업시 다이어 그램을 만드는게 좋다.

한 유저가 애플리케이션을 여러개 소유가 가능하다.

하나의 어플리케이션에 여러개 롤이 들어갈 수도 있고 결국엔 이렇게 하지 못하고 조인테이블 만듬. 어떤 애플리케이션이 어떤 role을 가졌는지 확인하기위해 role을 사. role이 반복적으로 안들어가게 이런식으로.

동업자들을 위해서 바로 접근 못하게 하고 조금씩 접근하기 위해 scpe 썼다.

이 scope은 role에 종속 role 하나가 여러개 scope 가질 수 있음.

다음은 애플리케이션 소유자는 아니지만 줄 권한을 위해서 접근용 엔티티 따로 만듬.

appkey가 여러개 있을 수 있고 하나의 유저가 있을 수 있다. 롤은 애플리케이션에 부여가 되는데 scope은 애플리케이션 기준으로 부여되고 유저가 쓰는건 애플리케이션에 있는 걸 쓰는게 아니라 app_key에 있는걸 사용하게 된다.

erd를 그리는 연습이 먼저 되어야 한다.

디비 mysql 언제 서비스가 복잡해지는가? 돈이 들어가면 복잡해짐. 현재의 상태에 돈을 취소했나 돈을 넣었나 이런식. 그래서 돈이 들어가면 복잡해진다. 으악

jpa 쓰면서 권한 잘 나누고 이런식으로 해야한다 쿼리를 딥하게 나눠서 들어간다 이런건 아님.

디비 어디까지 알아야 되나. 디비는 따로 공부 할 곳 까진 있다. 애초에 복잡한 서비스는 테이블 직접 만들 일은 없다. 게시판 crud하기 위한거 user,table, comment 좋아요 이런거. 복잡하게 하려면 했다가 취소했다 하면 더 복잡하게 하는 거.

프로시져랑 인덱싱 이런거

백엔드 개발자로 하려면 어느정도는 프로그래밍 자체에 대한 능력을 다룰수 있어야 한다. 자바만 하면 자바만 하는게 아니라 컴퓨터가 이해 할수 있는 언어학이라서 다른 언어 쓴다고 해서 작은 syntex차이가 많아서 컴파일 언어냐 인터프리터 언어냐 이런거라서 하나를 빡세게 파는거보다 다른거도 조금씩 알고 파는게 좋다. 디비도 마찬가지로 전동적인 rdb에서 jpa,넘어가고 nosql 쓰고 이런식이 되서.

어차피 이 진로로 가면 평생 공부하고 실전 테스트 하고 이런식이다.

JPA 쓰면 전통적인 쿼리 안 쓰게 되는 것도 있고

라이브러리 임포트 해서 받아오는거.

Java에서 DB 사용할 때

mysql 서버랑 디비랑 애플리케이션이 서로 소통하는거니까 connection 받아온다. 이게 원초적인 디비 활용하던 방법

• mybatis는

세션에서 사용하고자 하던 매퍼에서 가져와서 거기에 저장된 쿼리문을 사용. 마이바티스는 실제 쿼리문을 사용. 그러기 위해 인터페이스 정의 잘 하고 인터페이스를 가져옴.

외래키를 기본키에 넣으면 넣은 기본키를 다시 되받아와야하는데 쿼리 한번 날리고 값 받아와야하는거러 useGeneratedKey로 받아와야한다.

mybatis 사용시 dto로 정의 하고 자신이 넣고싶은 값 넣어서 매퍼 인터페이스를 통해 넣어주면 쿼리문을 통해 실행된다.

한 매퍼에 인서트 오퍼레이션을 위한건 반환값이 int로 응답이돌아오게 된다. 여기에 정의해서 넣어달라 했던 DTO에 반환한다.

이 useGeneratedKey 가 true면 이 아이디와 존재하는 id가 빈채로 돌려주지만 그 결과로 돌려받은 row에 채워져서 돌아옴.

useGeneratedKey, keProperty 둘다 mybatis에서 사용.

Maven vs Gradle

• 둘다 build automation tool maven 은 pom.xml

마이바티스든 jpa든 Dependency정의하는 부분에 라이브러리 관리하기 위한 큰 서버에 이 디펜던시 정의. 어떤 그룹에 어떤 아티팩트에 어떤 방법으로 정의할 건지.

scope는 어떤 빌드에서 어떤 부분에서만 정의할지. maven과 gradle은 스코프 차이가 중요하다.

maven은 겉으로는 보이지않지만 maven repository 에서 가져오는 라이브러리들은 로컬에 저장되어 빌드에 사용된다.

maven wrapper 플러그인도 존재한다.

파워쉘이나 터미널에서 실행시 메이븐이없을 떄를 대비해서 wrapper넣어두면 메이븐이 같이 남아있는 상태로 들어감.

gradle

scope 설정할 떄 이렇게 들어간다.

gradle 도 똑같이 maven repositroy에서 라이브 러리 사용하고 받아올 수 있다.

gradle은 maven과 가장 큰 차이가 inclemental build 사용.

gradle는 큰 테스트가 조금씩 나눠서 서브테스트로 관리. 자기가 원하는 task하나, 초기단계에서 gradle이 느리다고 느껴지지만 수정이 자주되고 하면 gradle이 더빠를 수있다.

사용하는 syntax도 groovy라 코틀린으로도 사용이 가능하다.

Gradle에서 특정한 task를 정의 가능하다. maven은 grpc는 프로토콜 사용하는데 신텍스가 있는데요 gradle은 task를 따로 만들어 줄수 있다. 도커파일 또한 configure가 가능하다. gradle이 자유롭고 빠르다.

보통은 코딩 에러가 되긴하는데 Dependency 떄문에 발생하는 경우도 있어서. 떡하니 오는 파일들이 아니다.

maven <-> gradle 이 가능한가?

jar파일인데 폴더별로 잘 정리 되어있는 거 뿐이지 디펜던시는 유사하지 결과적으로 jar형태로 받아오기위한 형태중 하나. 빌드 과정을 어떤식으로 가져가냐 maven에서 설정과 gradle설정은 좀 다름. maven은 task 설정하는 부분이 없음(디펜던시 설정시 플러그인 설정) gradle은 어떤 레포지토리 사용할건지. 완전히 상하위 호환이 가능한게 아니라 다른 목적을 가지고 나옴. 자바와 코틀린 관계와는 다름. 그레이들은 task 정의를 좀 더 가능.

maven 프로젝트는 라이프 사이클 하나 존재하고 라이프 사이클로 빌드 진행. 메이븐은 세부테스트 따로 진행. 여기 디펜던시를 가져다 따로 사용 가능하긴 함.

그냥 안된다라고 생각해도 되긴 함. 환경설정 및 사용하는 도구의 차이

mybatis 는 요새 jpa 가 더 확보가 되어있다. mybatis는 결과적으로 디비 관리 해줘야 할 사람이 있어야 한다. jpa도 있어야 하지만 디비를 직접적으로 다뤄야 하진 않아도 된다.

검색 하면 검색 내용에 따라서도 페이지 처리가 되게 해야한다.