til

해피데빙·2023년 5월 23일
0

git 개꿀팁

브랜치 A에 dependency를 가지고 있는 브랜치 B의 경우, A가 수정되면 이를 반영하기 위해 git rebase A를 해줘야 한다
하지만 B는 원래 A의 커밋들을 가지고 있기 때문에 rebase할 때 하나하나 merge conflict를 해줘야 한다.

이걸 피하는 꿀팁
1.A에서 수정한 커밋이 a라면 B에서 a까지 삭제한다 (이때 A에는 없고 B에만 있는 커밋이 날아가지 않도록 따로 저장을 해둔다 ex. 깃허브, 다른 브랜치 등)
2.B에서 A의 a부터 커밋을 cherry-pick하고 B에서 추가된 커밋도 cherry-pick한다
3. cherry-pick하면 픽한 원본 브랜치의 커밋과 다른 커밋이 되기 때문에 나중에 A를 기반으로 B를 합칠 때 crash가 날 수 있다. 그러므로 B에서 git rebase A를 해준다. 그럼 A에서 픽해온 커밋들이 A에서의 커밋으로 대체된다. ( 어차피 이름만 다르지 내용은 같은 커밋들이라 그런 듯)

끝!


0612

어디서 데이터를 가져올 것인가

  1. 프론트에서 라우팅해서 데이터 가져오는 방법
  • 바로 페이지에서 화면이 나오길 바랄 때 사용한다
  • 백엔드로 호출해서 데이터를 받아오면 올때까지 기다려야 화면을 볼 수 있는데 프론트는 애초에 라우팅 단계부터 데이터를 받아오니까 기다리는 시간을 단축할 수 있다
  1. 백으로 api 호출 해서 데이터 가져오는 방법
  • paging이 필요할 때 사용한다
    : 인피니트 스크롤 , 다른 페이지 등 어떤 액션에 대해서 loadMore로 새로운 데이터를 가져와야할 때 프론트에서 라우팅을 하고 있으면 이 액션을 감지할 수 없다. 그러므로 이런 액션이 있을 때마다 백엔드로 api호출을 해서 받아오도록 하는 것이 좋다.

DB

출처 : https://reasontaek.tistory.com/13

int

  • 4 byte
  • 범위 : -2147483648 ~ 2147483647
  • id에 음수를 사용하지 않기 때문에 UNSIGNED 속성을 지정하면, 0 ~ 4294967295의 범위

bigint

  • 42억 개의 데이터가 들어갈 일이 절대 없다면 BIGINT를 쓸 필요가 없다
  • 경우에 따라서 그보다 더 작은 타입들(MEDIUMINT, SMALLINT, TINYINT)을 고려할 필요가 있다.

결론 : 테이블에 따라 가장 작은 데이터 타입을 쓰면 된다.


INT 대신 BIGINT를 썼을 때 어떤 영향이 있을까?

  1. 디스크에서 페이지를 더 많이 사용한다.
  • 데이터가 램에 있지 않을 때 데이터 읽기 속도에 영향을 줄 수 있다.
  • 유지관리 작업이 더 오래 걸린다(백업, 인덱스 재구축, CHECKDB)
  1. 늘어난 데이터 페이지만큼 램에 더 많은 공간을 차지한다.
  • 디스크에서 더 자주 읽는 비용이 발생한다.

data type

  • 결과 데이터 형식 : char, varchar, text, nchar, nvarchar 또는 ntext. 결과의 데이터 정렬은 데이터 정렬 우선 순위 규칙에 따라 결정
    선행 정렬 유선 순위 참조

DB 데이터 무결성

  1. not null
  • 필수 입력사항
  • 데이터가 들어가기 전에 오류를 내도록 한다
  • null은 아예 입력이 되지 않음
  • null이 default 세티
  1. unique
  • 중복성 배제 (테이블 내 유일한 값)
  • 해당 테이블 내에서 존재하는 겂아 유일해야 함
  • insert or update 시 제약이 걸려있는 컬럼에 동일한 데이터가 나올 경우 오류 발생
  • null 값은 unique 제약 조건이 적용되지 않음.
    unique로 설정된 컬럼이어도 null이 가능한 컬럼이라면 null 데이터행이 여러개일 수 있음
  • constraints 키워드를 사용하여 제약조건의 이름을 명시.
    ex. (column_name2 + column_name3)의 조합이라면 이 조합이 유일해야 하는 것
  1. primary key
  • 한 테이블 내의 기본 키는 해당 테이블 내에서 데이터를 식별하기 위한 제약 조건
  • unique와 다르게 한 테이블 내 하나의 칼럼만 지정 가능
  • primary key : not null + unique의 속성. null값일 수 없으며 데이터는 해당 테이블 내 유일 명시 방법
  1. foreign key : 참조하는 테이블의 존재하는 값만을 사용. 참조하는 테이블의 키 값
  • check : 주어진 조건에 해당하는 값만 입력할 수 있음

--

profile
노션 : https://garrulous-gander-3f2.notion.site/c488d337791c4c4cb6d93cb9fcc26f17

0개의 댓글