git checkout vs git switch
| 기능 | git checkout | git switch |
| 브랜치 전환 | 가능 | 가능 |
| 작업 트리 변경 | 가능 | 가능 |
| HEAD 위치 변경 | 기본적으로 브랜치 끝으로 이동 | 옵션에 따라 다름 (기본값, 브랜치 끝, —detach 옵션: HEAD 분리) |
| 스테이징 영역 변경 | 가능 | 가능 |
| 로컬 변경 사항 손실 가능성 | 있음 (옵션에 따라 다름) | 없음 (옵션에 관계없이 항상 로컬 변동 사항 보존) |
| 옵션 | 다양 | 상대적으로 적음 |
* Generated by GEMINI
브랜치 끝이란 무엇일까요?
간단히 말하면, 브랜치 끝은 Git 브랜치에서 가장 최근 커밋이 있는 지점을 의미합니다. 즉, 브랜치에 추가된 모든 변경 사항이 포함된 지점입니다.
좀 더 자세히 설명하자면:
- Git 브랜치는 마치 시간 여행을 하는 것과 같습니다. 각 브랜치는 특정 시점의 프로젝트 상태를 나타냅니다.
- 브랜치 끝은 마치 시간 여행의 끝과 같습니다. 현재 브랜치에서 가장 최근에 도착한 시점입니다.
- 브랜치 끝은 HEAD라는 특별한 포인터로 표시됩니다. HEAD는 항상 현재 브랜치의 끝을 가리킵니다.
async (req, res) vs async (req, res, next)
async (req, res)와 async (req, res, next)는 둘 다 Express.js 라우터 핸들러에서 비동기 처리를 가능하게 하는 데 사용된다. 하지만 작동 방식과 용도에 있어 미묘하지만 중요한 차이점이 존재한다.
1. next 매개변수의 역할
- async (req, res) : next 매개변수를 사용하지 않는다. 이 핸들러에서 발생하는 에러는 자동으로 다음 미들웨어로 전달되지 않는다.
- async (req, res, next) : next 매개변수를 사용하여 에러를 다음 미들웨어로 전달하거나 라우터 핸들러 체인을 중단할 수 있다.
2. 에러 처리
- async (req, res) : 핸들로 내부에서 발생하는 에러는 직접 처리해야 한다. 일반적으로 try-catch 블록을 사용하여 에러를 감지하고 적절하게 응답을 보낸다. 하지만 에러 처리 코드가 핸들러 로직에 섞여 가독성을 떨어뜨릴 수 있다.
- async (req, res, next) : next(err)를 사용하여 에러를 다음 미들웨어로 전달할 수 있다. 에러 처리 코드를 분리하여 코드 가독성을 높이고, 에러 처리 로직을 중앙에 집중 관리할 수 있다.
3. 미들웨어 체인
- async (req, res) : 핸들러가 항상 응답을 완료해야 한다. 즉, 핸들러 내부에서 다른 미들웨어를 실행하거나 라우터 체인을 조작할 수 없다.
- async (req, res, next) : next() 함수를 호출하여 다음 미들웨어로 제어를 전달할 수 있다. 라우터 체인을 자유롭게 조작하고 다양한 기능을 구현할 수 있다.
4. 결론
- async (req, res) : 간단한 비동기 처리에 적합
- async (req, res, next) : 에러 처리, 라우터 체인 조작, 코드 재사용 등에 유용
3-Layered Architecture
Controller
- 주요 역할
- 비즈니스 로직을 구현한다.
- Repository Layer와 상호 작용하여 데이터를 처리한다.
- 여러 Repository 레이어를 통합하여 복잡한 비즈니스 로직을 수행한다.
- 핵심 기능
- 데이터 검증 및 변환을 수행한다.
- 비즈니스 규칙을 적용한다.
- 여러 데이터 소스를 통합한다.
- 트랜잭션 관리를 수행한다.
Service
- 주요 역할
- 비즈니스 로직을 구현한다.
- Repository Layer와 상호 작용하여 데이터를 처리한다.
- 여러 Repository 레이어를 통합하여 복잡한 비즈니스 로직을 수행한다.
- 핵심 기능
- 데이터 검증 및 변환을 수행한다.
- 비즈니스 규칙을 적용한다.
- 여러 데이터 소스를 통합한다.
- 트랜잭션 관리를 수행한다.
Repository
- 주요 역할
- 데이터베이스와 상호 작용하여 데이터를 추가, 조회, 수정, 삭제한다.
- SQL 쿼리를 작성하고 실행한다.
- 데이터베이스 쿼리를 최적화한다.
- 데이터 접근 권한을 제어한다.
RDB의 1:N 관계
orderdetail에서는 전체에 대해서만 구분한다 주문됐냐? 배달 시작했냐? 등등
order에서는 메뉴 하나에서 등등 ..
1. 1:N 관계 정의
1.1 개념
RDB에서 1:N 관계는 하나의 테이블(부모 테이블)의 레코드가 다른 테이블(자식 테이블)의 여러 레코드와 연결되는 관계를 의미합니다. 부모 테이블의 하나의 레코드는 자식 테이블의 0개 이상의 레코드와 연결될 수 있지만, 자식 테이블의 하나의 레코드는 반드시 부모 테이블의 하나의 레코드와 연결되어야 합니다.
1.2 비유
1:N 관계는 현실 세계의 다양한 상황을 비유하는 데 사용됩니다. 예를 들어:
- 학교: 한 명의 선생님은 여러 명의 학생을 가르칠 수 있습니다. (선생님: 학생 = 1:N)
- 회사: 한 명의 부서장은 여러 명의 직원을 관리할 수 있습니다. (부서장: 직원 = 1:N)
- 도서관: 한 권의 책은 여러 명의 독자가 빌릴 수 있습니다. (책: 독자 = 1:N)
2. 1:N 관계의 특징
2.1 주요 특징
- 참조 무결성: 자식 테이블의 외래 키 값은 항상 부모 테이블의 주 키 값과 일치해야 합니다.
- 부모 테이블 삭제: 부모 테이블의 레코드가 삭제되면 해당 레코드와 연결된 자식 테이블의 모든 레코드도 함께 삭제됩니다.
- 자식 테이블 삭제: 자식 테이블의 레코드가 삭제되더라도 부모 테이블의 레코드는 영향을 받지 않습니다.
2.2 추가 특징
- 부모 테이블의 역할: 부모 테이블은 자식 테이블에 대한 정보를 제공하는 역할을 합니다.
- 자식 테이블의 역할: 자식 테이블은 부모 테이블에 대한 상세 정보를 제공하는 역할을 합니다.
3. 1:N 관계 구현
3.1 테이블 설계
1:N 관계를 구현하기 위해서는 두 개의 테이블을 설계해야 합니다.
- 부모 테이블: 부모 테이블은 1:N 관계에서 "1"에 해당하는 테이블입니다. 부모 테이블은 주 키를 가지고 있어야 합니다.
- 자식 테이블: 자식 테이블은 1:N 관계에서 "N"에 해당하는 테이블입니다. 자식 테이블은 외래 키를 가지고 있어야 합니다.
3.2 외래 키
3.2.1 정의
자식 테이블은 부모 테이블과의 관계를 나타내는 외래 키를 가지고 있습니다. 외래 키는 부모 테이블의 주 키와 일치하는 값을 가지고 있어야 합니다.
3.2.2 종류
- 필수 외래 키: 자식 테이블의 모든 레코드는 반드시 부모 테이블의 주 키 값과 일치하는 외래 키 값을 가지고 있어야 합니다.
- 선택적 외래 키: 자식 테이블의 일부 레코드는 부모 테이블의 주 키 값과 일치하지 않아도 됩니다. 이 경우, 외래 키 값이 NULL일 수 있습니다.
* Generated by GEMINI
RDB의 N:M 관계
1. N:M 관계 정의
1.1 개념
RDB에서 N:M 관계는 두 테이블 사이에서 다대다 관계를 나타냅니다. 즉, 한 테이블의 하나의 레코드는 다른 테이블의 여러 레코드와 연결될 수 있으며, 반대로 다른 테이블의 하나의 레코드도 첫 번째 테이블의 여러 레코드와 연결될 수 있습니다.
1.2 비유
N:M 관계는 현실 세계의 다양한 상황을 비유하는 데 사용됩니다. 예를 들어:
- 학생과 수업: 한 명의 학생은 여러 수업을 수강할 수 있으며, 한 수업은 여러 학생이 수강할 수 있습니다.
- 영화와 배우: 한 영화는 여러 배우가 출연할 수 있으며, 한 배우는 여러 영화에 출연할 수 있습니다.
- 사람과 취미: 한 사람은 여러 가지 취미를 가질 수 있으며, 한 가지 취미는 여러 사람이 가질 수 있습니다.
2. N:M 관계의 특징
2.1 주요 특징
- 참조 무결성: N:M 관계는 직접적으로 구현되지 않습니다. 대신, 연결 테이블이라는 중간 테이블을 사용하여 구현됩니다. 연결 테이블은 두 테이블의 주 키를 외래 키로 가지고 있습니다.
- 데이터 중복: N:M 관계는 데이터 중복을 발생시킬 수 있습니다. 예를 들어, 학생과 수업 관계에서 학생 정보는 학생 테이블과 수강 테이블에 모두 저장됩니다.
2.2 추가 특징
- 다대다 관계의 표현: ERD(Entity Relationship Diagram)에서 N:M 관계는 다이아몬드 모양으로 표현됩니다.
- 연결 테이블의 역할: 연결 테이블은 두 테이블 간의 관계에 대한 추가 정보를 저장하는 데 사용될 수 있습니다.
3. N:M 관계 구현
3.1 테이블 설계
N:M 관계를 구현하기 위해서는 다음과 같은 세 개의 테이블이 필요합니다.
- 두 개의 주 테이블: N:M 관계에 참여하는 두 테이블입니다. 각 테이블은 각각의 엔터티를 나타내는 주 키를 가지고 있어야 합니다.
- 연결 테이블: 두 주 테이블의 주 키를 외래 키로 가지고 있는 중간 테이블입니다. 연결 테이블은 두 테이블 간의 관계를 나타냅니다.
3.2 연결 테이블
- 구성: 연결 테이블은 두 주 테이블의 주 키를 외래 키로 가지고 있으며, 추가적인 속성을 가질 수도 있습니다.
- 주 키: 연결 테이블은 일반적으로 두 외래 키를 조합한 복합 주 키를 가지고 있습니다.
- 참조 무결성: 연결 테이블의 외래 키는 항상 두 주 테이블의 주 키 값과 일치해야 합니다.
* Generated by GEMINI
order는 status만 알 수 있다.
detail은 각각에 대해서만 알 수 있다.
id와 orderId를 연결하여 타고타고 이동해서 다른 테이블에 접근하여 값을 파악한다.
3계층 api URL 설정!
- app.js에서 1차 라우팅 설정
- routes/index.js에서 2차 라우팅 설정
- menus.router.js에서 3차 라우팅 설정
- restaurant.router.js에서 3차 라우팅 설정
- users.router.js에서 3차 라우팅 설정
api/menu - 2차
Api/menu/menuId - 3차
CRUD … POST/GET/PATCH/DELETE
굳이 api URL로 해줄 필요 없다 ~ …
3차에서 가공 후 모듈 함수로 넘어가면 된다.
'Coding > 내일배움캠프' 카테고리의 다른 글
| [내일배움캠프] 배달 음식 주문하기 | Node.js 4기 TIL | Day 55 | 24.02.28.(수) (0) | 2024.02.28 |
|---|---|
| [내일배움캠프] 3-Layered Architecture에 대한 이해 | Node.js 4기 TIL | Day 54 | 24.02.27.(화) (0) | 2024.02.27 |
| [내일배움캠프] Node.js 4기 TIL | Day 52 | 24.02.23.(금) (0) | 2024.02.24 |
| [내일배움캠프] Node.js 4기 TIL | Day 51 | 24.02.22.(목) (0) | 2024.02.22 |
| [내일배움캠프] Node.js 4기 TIL | Day 50 | 24.02.21.(수) (0) | 2024.02.22 |
