[데브코스] 주문 조회 api

주문 조회 api 추가

postman 폴더로 깔끔하게 정리하니 보기 좋고 재미잇음 

 

오늘은 db 테이블 만드는거만 강의 내내 한 것 같은데...내가 착각 하고 있었던 것을 발견햇다.

 

fk 네이밍 중 fk_0000_0000_id 형식으로 쓰는데, 나는 fk_테이블명_아이디명(user_id, book_id...)인 줄 알았는데 fk_테이블명_참조하는 테이블명_id 형식으로 쓰고 계신거였다. 확실히 fk 정보를 파악하기엔 훨씬 용이한 구조 같긴 한데, 테이블명이 단일 단어가 아닌 orderd_books 처럼 조합된 단어라면 지나치게 길어지는 문제가 있기 때문에, 차라리 테이블명은 제외하고 fk_book_id 형식으로 쓰는게 좋지 않을까 생각이 들기도 한다. fk_orderd_books_books_id...? fk_orderd_books_id? 흠....

코드를 쓸 때 중요한 요소 중 하나가 '가독성'이고, 보통 가독성이라 하면 간결한 코드를 의미하는 바일텐데, 막상 더 생각해보면 가독성이라는게 얼마나 쉽게 읽히느냐를 넘어서 쉽게 읽고, 정체를 파악할 수 잇느냐 관점으로도 볼 수 잇을것 같다. 이런 측면에서는 한번에 테이블 간 참조 관계를 파악할 수 있는 긴 네이밍이 유리하지 않나 싶기도. 지나치게 길어도 정보가 충분한 네이밍 vs 기본적인 정보는 가지되 간략한 네이밍 고민이 많이 되는 것 같다. 일단 난 구구절절한거 좋아하기도 해서 긴 네이밍이 더 취향이긴 함. 결국 취향으로 결정되는 문제이기도 하고,,,이래서 컨벤션이라는게 생겼나 싶다

 

프로젝트 중간중간 계속 테이블을 추가하는 방식으로 하고 있는데 이로 인해 중간에 테이블을 수정해야 하는 경우도 종종 있고, 필드 네이밍도 중간중간 수정되니 통일성이 떨어진다. 설계의 중요성을 새삼 깨닫고 있음. 그래도 필요할 때마다 추가하면서 실습하니 어디서 필요한지, 테이블 간 관계는 어떻게 되는지 이해하기에는 편한 것 같다. 테이블 관계 파악에 항상 애를 먹었는데,, 점점 익숙해지고 있음