인덱스와 쿼리 속도

Today I Learned 날짜 2025년 2월 6일 목요일 내용 is와 ==의 차이 네이버 커머스 솔루션 관련 버그를 고치던 중, 네이버 스토어 데이터에도 샵의 비활성화 여부를 나타내는 필드를 추가해야 했다. 따라서 NaverStore 테이블에 is_active 필드를 추가했다. 이제 스토어를 탐색하는 경우의 대부분은 ‘활성화된 스토어’를 기준으로 하는게 당연해졌으므로 탐색 함수에 is_active 필드가 True인 경우를 추가해줬다. 따라서 1 2 3 stmt = select(models.NaverStore).where( models.NaverStore.is_active == True ) 이런식으로 쿼리를 작성했다. 그런데 Flake8에서 경고 메시지가 떴다. ...

2025년 2월 6일 · 2 분 · 배준수

Postgresql Secondary Table에 필드 추가하기

Today I Learned 날짜 2024년 12월 24일 화요일 내용 secondary table에 필드를 추가하기 네이버 배너이미지에는 인스타그램 게시글의 사진이 포함될 수 있다. 한 게시글은 당연히 여러 이미지에 포함될 수도 있다. many to many를 설계 과정에서 어떻게 처리할지 고민하다가 secondary table로 구현했다. id로 4를 가진 네이버 배너이미지데이터가 생성되고 이 배너이지에 포함되는 게시글 3개의 id가 1,3,5라면 naver_banner_image_id instagram_post_id 4 1 4 3 4 5 secondary table에는 이렇게 저장이 된다. 만약 id가 12인 네이버 배너이미지가 생성되고 게시글을 3,5,22 를 id로 하는 데이터들을 포함한다면 ...

2024년 12월 24일 · 2 분 · 배준수

uselist, passive_delete, cascade

Today I Learned 날짜 2024년 10월 10일 목요일 내용 데이터베이스 설정의 의미 데이터베이스에서 고민이 생겼다. 오른쪽에 있는 네이버 관련된 부분을 작성해야 했는데, 다음과 같은 조건을 만족해야했다. 네이버 스토어는 여러개의 네이버 이미지 배너를 가질 수 있다. 네이버 이미지 배너는 하나의 네이버 상품과 관련될 수 있다. 네이버 이미지 배너는 다수의 인스타그램 게시글과 관련될 수 있다. 네이버 상품과 네이버 이미지 배너는 네이버 스토어의 자식테이블이다. 중복된 데이터 생성은 최대한 방지한다. 이미지 배너 데이터가 삭제되더라도 네이버 상품과 인스타그램 게시글 데이터는 삭제되선 안된다. 어렵다.. 사실 5번만 무시(?) 한다면 일은 훨씬 쉬워진다. 그냥 네이버 배너이미지 테이블 밑에다가 중복된 데이터를 저장하는 테이블을 2개 만들고 관계가 생성되면 복붙해서 넣어주면 된다. 하지만 중복된 데이터는 효율성이나 리소스 낭비의 문제도 있지만 데이터 무결성과도 연관이 있다. 똑같은 데이터가 2개 있을 때, 하나가 삭제되면 반드시 다른 하나가 삭제되야 하는데 그렇지 않게 될 경우 발생할 수 있는 위험성들이라던가.. ...

2024년 10월 10일 · 6 분 · 배준수

간간히 유지보수

Today I Learend 날짜 2024년 3월 18일 월요일 내용 아직 스프린트가 끝나지 않았지만, 프론트 쪽 일정이 진행되는 동안 유지보수 작업을 시작했다. 프론트 쪽이 주 작업인데, 기존에 항상 설정되어 있던 placeholder를 서버에서 받은 세팅값이 False일 경우에는 세팅하지 않도록 한다던가, 현재 우리의 소개페이지(랜딩페이지)에 작동안되는 버튼들을 정리하고 다른 URL로 연결하는 간단한 작업들이 었다. 다만 아직 프론트 코드들은 익숙하지 않아서 기존의 구조를 망가뜨리지 않도록 잘 살펴보면서 하긴 했다. 작성된 리뷰를 보여주는 위젯에는 ‘더보기’ 기능이 있다. 말 그대로 내용이 길 경우 일부만 보여주고 모든 내용을 보기 위한 버튼이어야 정상인데 지금은 이미지만 확대된다. 내용은 아무리 길어도 다 출력된다. 이 기능을 정상적으로 되돌려야 한다. 위젯은 HTML로 서버에서 렌더링하여 제공하는데, 여기에 사용되는 더보기 관련 스크립트가 Shopify 프론트 쪽에 구현되어 있는 것 같다. 이게 맞나..? ...

2024년 3월 18일 · 1 분 · 배준수

scalars의 사용 이유

Today I Learend 날짜 2024년 3월 15일 금요일 내용 scalars()의 역할 PostgreSQL에서 데이터를 가져올 떄 다음과 같은 형식을 사용했었다. 1 2 stmt = select(models.Product).where(models.Product.title != "가짜") result = db.execute(stmt).scalars().all() scalars()를 왜 써야하는지 모르는 채, 그냥 기존 코드가 그렇길래 써왔었다. 오늘 위젯 렌더링을 구현하는 과정에서 jinja2 템플릿을 이용해 위젯 HTML에 상품들의 목록을 넣어줬지만 해당 값의 필드들을 참조할 수 없었다. 1 2 3 4 5 stmt = select(models.ListDesignerProduct) .where(models.ListDesigerProduct.list_designer_widget_id == 1) result = db.execute(stmt).all() for product in result: logging.info(product.id) 이런식으로 작성되어 있었다. 이때 저 result를 직접 로깅해보니 row라고 나오면서 내부 필드를 참조할 수 없다고 오류가 발생했다. ...

2024년 3월 15일 · 1 분 · 배준수

데이터베이스의 사용성 고려해보기

Today I Learned 날짜 2024년 2월 29일 목요일 내용 데이터베이스 계획 변경 다음 주에 시작될 스프린트의 공수와 일정을 확정짓는 플래닝미팅에 들어가기 전 마지막으로 PRD 기획 문서와 피그마를 체크했다. 기존에 열심히 고민하고 공부해서 이번에 추가될 데이터베이스 테이블을 짰는데, 몇가지 놓친 부분이 있어 크게 변경했다. 사용방식 기존 ERD 상으로, 위젯 테이블은 2개의 연관된 자식 테이블을 가지게 된다. 데이터 설정의 기준을 담는 테이블과 위젯에 포함되는 상품에 대한 테이블이다. 어제, 그제 열심히 고민한 부분은 후자였다. 하나의 상품이 위젯에 포함되는 갯수만큼 데이터를 만들 것인지, 상품 당 하나만 가지고 있을지. 전혀 생각하지 못한 부분이 뒤늦게 떠올랐고 의미없는 고민임을 알게됐다. 각 위젯은 데이터를 포함하기 위한 기준을 설정해야 한다. 예를 들어, 최근 이 상품을 구매한 고객에 정보의 최대 기준을 1일, 7일, 30일 등으로 가능하다. 똑같은 상품을 10일전에 김씨가 주문했어도 어떤 위젯에서는 최근 구매정보가 없다고 입력되야 하고 다른 위젯에서는 이 정보가 입력되야 한다. 같은 상품이라고 모두 정보가 같다는 보장이 없다는 의미이다. 따라서 각 상품은 위젯에 포함된 갯수만큼 데이터 정보를 가지고 있는게 맞았다. 황소 뒷걸음질 치다 쥐 잡은 꼴이네. ...

2024년 2월 29일 · 3 분 · 배준수

SQL은 어려워

Today I Learned 날짜 2023년 12월 19일 화요일 내용 너무 힘들다. 흑흑 SQL 데모 로그인은 로그인의 로직을 이용해 만들었다. 로그인 함수가 호출되면, 해당 계정 정보가 관계를 갖고 있는 shop들을 불러와 shops 라는 배열에 담는다. 데모 로그인 때는, 가져온 후 데모로 설정한 shop_id와 일치하는 것만 남기도록 처리하였다. 이 과정이 DB에 영향을 끼치지 않도록 하기 위해, DB에 최근 접근 시간을 업데이트하고 commit하는 이후에 해당 로직을 추가하였다. shop들을 가져와 배열에 담는 joinedload에 특정한 조건을 추가하는 코드를 작성해야 했다. 사실 이 부분에서도 많이 헷갈렸는데, joinedload가 일반 join과 다른 점은 eager loading이라느 것이다. 간단히 말하자면 lazy-loading은 레코드를 조회할 때 연관관계가 있는 데이터들의 조회를 필요한 순간까지 미루는 것이고 eager-loading은 레코드를 조회할 때 연관이 있으면 다 가져와놓는 것이다. 지금 고민하는 부분과는 다른 이야기이니 차치하고, join과는 언제 연관된 데이터를 갖고 오느냐만 다르다는 의미이다. ...

2023년 12월 19일 · 2 분 · 배준수

Teamsparta Devcamp를 마치며

Devcamp 팀스파르파 부트캠프(정글, 항해, 내일배움캠프) 출신들이 이커머스 쇼핑몰의 핵심 로직을 만들어보는 3주 과정이다. 난 조금 길어져서 10월 2일에 시작해서 10월 27일에 마무리됐다. 팀은 5~6명 정도로 구성되는데 10월의 경우에는 4명의 프론트엔드와 유일한 백엔드인 내가 한 팀이었다. 강의로 혼자 공부, 로그인 및 회원가입 구현, 장바구니 및 결제가 각각 1주일씩 진행된다. 만족할 만한 수준으로 학습이 되지 않거나, 완성도가 떨어지거나 여러 기준으로 충분하지 못하다고 판단되면 다음 단계로 넘어가지 못한다. 백엔드는 NestJS, TypeORM, PostgreSQL, AWS 를 사용한다. 프론트엔드는 Next.js랑 TailwindCSS, Vercel이다. 언어는 Typescript ...

2023년 10월 27일 · 3 분 · 배준수