#관계형

채팅 디비 설계 질문이요!

안녕하세요:) 저는 ! 웹소켓과 관계형디비+프리즈마 를 이용해서 백엔드를 구성하고, 리액트로 만든 프론트 와 양방향 채팅 서비스를 만들려고 합니다! 채팅방 DB스키마를 작성하는데 어려움을 겪어 질문을 남깁니다. 현재 프리즈마에서 model ChatRoom { id Int @id @default(autoincrement()) name String creatorId Int users ChatRoomUser[] messages Message[] createdAt DateTime @default(now()) updatedAt DateTime @updatedAt } model ChatRoomUser { id Int @id @default(autoincrement()) userId Int // 외부 API에서 가져올 사용자 ID chatRoomId Int chatRoom ChatRoom @relation(fields: [chatRoomId], references: [id]) createdAt DateTime @default(now()) updatedAt DateTime @default(now()) @@unique([userId, chatRoomId]) } model Message { id Int @id @default(autoincrement()) chatRoomId Int senderId Int // 외부 API에서 가져올 사용자 ID receiverId Int? // 선택적 필드, 단체 채팅에서는 null content String timestamp DateTime @default(now()) chatRoom ChatRoom @relation(fields: [chatRoomId], references: [id]) createdAt DateTime @default(now()) updatedAt DateTime @default(now()) } 이런식으로 구현하였는데 조언좀 부탁드립니다.ㅠㅠ

프론트에서는 관계형디비로 되어있는 백엔드에서 주는 응답 그대로 타입으로 써야하나요?

안녕하세요 예를들어 서버에서 아래와같이 응답을 준다고 할떄 end point : aimal/[id] response : { id:1 name:'코끼리', weight:1000, color: 'grey' } end point : getAnimals response:{ total_length:1, data:[{ id:1 name:'코끼리', weight:1000, } ] } 물론 위의 예시처럼 갑자기 배열로 호출시 특정 키(위 예시에서는 color)를 빼는 경우는 없겠지만, 비즈니스 로직을 처리하다보면 위와 같이 특정 api에서는 딱히 필요없는 값이라서 특정키가 빠지는 경우가 있더라구요 그런데 프론트엔드 입장에서 type Animal = { id:number; name:string; weight:number; color:Color } 이런식으로 타입을 정의해놓으면 특정 키가 들어오지 않았을 때 대응이 안되서 결국 모든 키를(id같은 특수 키 제외)nullable하게 해야하는것 같은데 좀 이상하기도 하고... 일반적으로 이런경우는 어떻게 해결하시나요?

관계형 디비 api설계와 프론트엔드에서 처리

관계형 데이터베이스를 사용중인데 총 10개의 칼럼이있는 테이블1과 총 13개의 칼럼이있는 테이블2 를 조인해서 응답해주는 API가 있는데요, 화면에서 필요한 칼럼은 테이블1에서 3개, 테이블2에서 5개 입니다. 이럴 때 테이블2개를 조인해서 카8개를 가진 json으로 리턴해주고 있는데요, 프론트엔드에서 테이블1에 해당하는 타입과, 테이블2에 해당하는 타입을 이미 지정해 놓아서 해당 방식으로 리턴해주면 조인을 하는 API마다 새로운 타입을 정의해야되서 조금 불편한것같다 라는 의견이 있었습니다. 보통 관계형 데이터베이스를 사용해서 조인 후 리턴하는 경우 api는 어떻게 설계하는게 좋을까요?

백엔드에서 이미지 저장 로직 관련해서 궁금한 점이 있습니다!

관계형 데이터베이스에서 이미지 처리에 대해 이 방법이 최선인지 궁금합니다. 1. 프론트에서 이미지 파일 형태로 서버로 보냅니다. 2. 서버에서 받은 이미지를 aws s3에 저장합니다. 3. 서버에서 데이터베이스의 s3에 저장된 이미지의 주소를 저장합니다. 프론트에서 이미지를 인코딩하고 보내거나 백엔드에서 인코딩해서 저장하는 방법도 있지만 이거는 잘 사용하지 않는 것으로 알고 있는데 위 방법이 최선일까요??

관계형 DB의 UNIQUE KEY duplicate 이슈

Duplicate 이슈를 막기위해 보통 insert 하기전에 조회 후 없으면 insert 쿼리를 날리는데 이럴 경우 스레드 환경에서 동시 쿼리가 실행될 경우 Duplicate 이슈가 생길 수 있습니다 Lock 을 이용하여 방지하는 방법도 있지만 성능을 떨어트리는 등 비용이 크다고 생각됩니다.  그래서 저는 insert ignore 쿼리를 통해 조회하지 않고 insert ignore 쿼리를 날린 후 조회하는 방법을 주로 이용합니다. 하지만 주변 지인분들은 잘 모르고 안쓰는 것 같더라구요.. 이 방법이 좋은 방법은 아닌가? 라는 생각에 다른분들은 어떻게 처리하고 계신지 궁금합니다.

백엔드 개발자 취업 준비 질문있습니다!

ROTC 복무 마치고 올 6월 전역하는 개발자 취준생입니다. 개발자분들께 관련 몇가지 궁금한 점 있어 질문 올립니다! 인서울 4년제 전공자이고 학점은 3점 초중반입니다. 군생활동안 인프라 관리 업무를 수행했는데, 이 경험을 살려 인프라+클라우드 쪽으로 진로를 정해볼까 고민했지만, 흘러가는 대로 간다면 후회할 것 같아 개발자를 도전해보려고 합니다. 현재 개인토이프로젝트 제외 제대로 해본 프로젝트 경험은 학부생 시절 node.js(express), react native, mongoDB 이용 모바일 어플리케이션 개발이고, 이와 관련해 깃허브 바탕으로 기억을 더듬어 가며 포트폴리오 작성중입니다. 추가적으로 궁금한 점은 1. 관계형 DB사용한 프로젝트 하나 더 진행하여 포트폴리오 작성하려고 하는데, 백엔드 포트폴리오 추천하는 포맷이 있는지? (어떤 요소가 반드시 들어가야 하는가) 2. 지금까지 개인 프로젝트 개발은 node.js, python 기반으로 해왔는데, 대한민국에서 개발자 하려면 현실적으로 Java Spring을 공부하는 것을 추천하는지? 3. 개발 채용 공고를 살펴봤을 때, 네카라쿠배와 같은 IT서비스 기업 이외에 소규모 스타트업 등은 경력개발자 채용이 대다수로 보이는데, 실무경험을 위해서 신입개발자는 어디서 경력을 쌓는것이 좋은지? 부족한 점이 많지만 개발자로 성장하기 위해서 한마디 첨언 해주시면 감사하겟습니다

자바 백엔드 개발자로 취업에 성공했습니다. 회사 출근까지 한 달 반 정도 남아 있는데 그 동안 무엇을 더 준비하면 좋을까요?

첫 출근은 내년 2월 6일이라 시간이 좀 있는 상황입니다. 굉장히 가고 싶었던 기업이고 어렵게 취업에 성공한 거라서 정말 잘해보고 싶습니다. 남은 시간 동안 어떤 것을 더 공부하면 좋을까요? 제 상황을 설명하면 우선 Java 기본 문법 및 Stream API, Spring Framework과 관계형 DB or 비관계형 DB 사용해서 간단한 REST API 를 만들어본 경험이 있고 기본적인 디자인 패턴도 공부 했습니다. (Singleton, Strategy, Observer, 등) 선배님들의 많은 조언 부탁드립니다!

관계형 DB 설계 시 카테고리 같은 것은 어떻게 저장하시나요?

안녕하세요. 이번에 기능을 구현하다가 문득 궁금해져서 질문납깁니다. 요구사항은 게시글에 카테고리가 추가되고, 해당 카테고리에 따른 게시글을 모아보는 페이지와 네비게이션을 생성하는 작업입니다. 네비게이션에서 게시글 카테고리를 클릭하면 해당 카테고리의 게시물들을 보여주는게 주 목적입니다. 게시글이 post로 MySQL에 저장되고 있는데 여기에 category라는 값을 추가하려고 하는데요. 질문은 카테고리를 어떤 형태로 저장하는게 좋은가 입니다. 기존 코드와 DB 설계 (다른 유사한 테이블)를 살펴보면 category라는 값을 숫자로 저장시키고 사용하는 서비스에서 각 숫자에 맞는 설명?타입을 선언하는 방식이더라구요. 예를 들면, DB에 category = 1로 저장된 post는 사용하는 서비스 (서버)에서 enum 또는 const로 선언해서 category = 1이면 PostCategory.Article 타입을 같는 형태입니다. 이후 사용자가 보게되는 프론트에서도 유사하게 category에 따른 카피를 보여주고 있어요. 특이사항이 있다면, 프론트에서 category에 따라 보여지는 카피는 수시로 바뀔 수 있을 것 같아요. 예를 들면, category = 1인 Article 타입이라면 카피 문구가 “논문”이라고 했을때, 나중에 카피가 “기사” 같은 것으로 바뀔 수 있어요. 이렇게 category 처럼 데이터의 속성이 잘 안바뀌는 값은 숫자로 정의하고 사용하는 위치마다 그에 맞게 타입을 선언하는게 좋을까요? 아니면 category를 DB에 만들때 문자열 형태로하고 “article”이라는 값을 바로 DB에 저장하는게 좋을까요?

NoSQL과 RDBMS의 가장 큰 차이가 무엇인가요?

안녕하세요, 비전공자 출신으로 부트캠프를 수료하고 있는 취준생입니다. 저는 산업공학을 전공했는데, 학교 수업에서는 관계형 데이터베이스에 대해서만 배웠습니다. 그런데 최근 NoSQL이라는 기술을 많이 사용한다고 하더라구요. RDBMS에 비해 더 유연하게 사용할 수 있다는 정도는 알고 있는데, 실제 서비스의 DB를 설계할 때 어떤 큰 이점이 있는지 궁금합니다. 미리 감사드립니다!