Fix/reservation category#113

[koreanddinghwan]

• 쿼리 관련해서 저렇게 처리하는 방법밖에 떠오르질 않네요(좋지 않음)

• prisma를 사용하다보니, 복잡한 쿼리를 표현하려면 raw쿼리를 사용해야하는데, 유지보수관점에서 좋지 않을 것 같습니다.

• prisma자체가 join을 지원하지 않으니, 이렇게 처리해도 성능상으로는 비슷할 것 같습니다.

• 트랜잭션 추가했습니다. 트랜잭션 처리 안하면 reservation create할때 500에러 발생 가능성 있습니다.

[koreanddinghwan]

profile이랑 hashtag junction table 해제하고, 명시적으로 선언하면 이벤트루프 블로킹하는 방식말고, 프리즈마 내에서 처리될 것 같은데 그렇게 바꿔볼까요?

[JuneParkCode]

profile이랑 hashtag junction table 해제하고, 명시적으로 선언하면 이벤트루프 블로킹하는 방식말고, 프리즈마 내에서 처리될 것 같은데 그렇게 바꿔볼까요?

profile-hashtags many to many 관계를 가지게 하지 않고 별도의 테이블로 두자는 말씀이신지?

[koreanddinghwan]

profile이랑 hashtag junction table 해제하고, 명시적으로 선언하면 이벤트루프 블로킹하는 방식말고, 프리즈마 내에서 처리될 것 같은데 그렇게 바꿔볼까요?

profile-hashtags many to many 관계를 가지게 하지 않고 별도의 테이블로 두자는 말씀이신지?

네네 _profiles_hashtags 이거 말씀드리는 겁니다 저희가 직접 컨트롤하죠

[JuneParkCode]

직접 컨트롤 했을 때 이점이 어떻게 되나요?
처음 스키마 설계할 때 그렇게 하려다가, 별 문제 없기도해서, prisma한테 맡겼던 부분입니당..

[koreanddinghwan]

직접 컨트롤 했을 때 이점이 어떻게 되나요? 처음 스키마 설계할 때 그렇게 하려다가, 별 문제 없기도해서, prisma한테 맡겼던 부분입니당..

junction table이라고 불리더라구요.

위처럼 manytomany로 만들어지는 테이블들 장점이 ORM에서 편하게 만들어준다는게 큰 장점입니다.

• 사실 ORM없으면 원래 저런 테이블들을 하나하나 만들어줘야하거든요.

이게 단점이 관계에 대한 추가적인 설명을 붙일 수가 없다는 겁니다.
프로필_해시태그라는 관계에 대해서 이 관계가 맺어졌다는 것만 추가할 수 있고, 언제 만들어졌는지, 누가만들었는지에 대한 정보는 저장을 하지 못합니다.

근데 제가 지금 저걸 만들려고하는 이유는 hashtag유효성 검증때문인데요,
카테고리와는 다르게 해시태그는 유저쪽에서 여러개의 해시태그를 예약에 넣을 수 있습니다.
서버측에서는 이 해시태그를 멘토프로필이 들고있는지 검증해야하구요.

멘토프로필의 해시태그는 임의의 N개이고, 유저가 입력한 해시태그도 임의의 N개기때문에 지금 어플리케이션 레벨에서 nn 으로 돌아갑니다.
(사실 예약에 들어가는 해시태그 최대 개수가 5개라서 5N)

[JuneParkCode]

그러면 유효성 검증을 ProfileHashtags.find 와 같은 방법으로 존재하는지 찾아내자..! 하는 아이디어인가요?
hashtag의 경우 profile 에서 max 5, 유저 paylaod 에서 max 5 라서 최대 25 라서 저는 굳이 필요할까? 하는 생각이 들었습니다.
사실 별도로 저희가 컨트롤할 수 있으면 좋긴 하지만요.

[koreanddinghwan]

직접 컨트롤 했을 때 이점이 어떻게 되나요? 처음 스키마 설계할 때 그렇게 하려다가, 별 문제 없기도해서, prisma한테 맡겼던 부분입니당..

junction table이라고 불리더라구요.

위처럼 manytomany로 만들어지는 테이블들 장점이 ORM에서 편하게 만들어준다는게 큰 장점입니다.

• 사실 ORM없으면 원래 저런 테이블들을 하나하나 만들어줘야하거든요.

이게 단점이 관계에 대한 추가적인 설명을 붙일 수가 없다는 겁니다. 프로필_해시태그라는 관계에 대해서 이 관계가 맺어졌다는 것만 추가할 수 있고, 언제 만들어졌는지, 누가만들었는지에 대한 정보는 저장을 하지 못합니다.

근데 제가 지금 저걸 만들려고하는 이유는 hashtag유효성 검증때문인데요, 카테고리와는 다르게 해시태그는 유저쪽에서 여러개의 해시태그를 예약에 넣을 수 있습니다. 서버측에서는 이 해시태그를 멘토프로필이 들고있는지 검증해야하구요.

멘토프로필의 해시태그는 임의의 N개이고, 유저가 입력한 해시태그도 임의의 N개기때문에 지금 어플리케이션 레벨에서 n_n 으로 돌아갑니다. (사실 예약에 들어가는 해시태그 최대 개수가 5개라서 5_N)

맞아요 최대 5개긴한데, 클라이언트의 요청이 1개일때는 25이고, 클라이언트의 요청이 100개일때는 2500이죠. 근데 저걸 데이터베이스 계층에 던져서 처리하게끔하면 어플리케이션 레벨에서는 부담하는게 적어지겠죵

[koreanddinghwan]

직접 컨트롤 했을 때 이점이 어떻게 되나요? 처음 스키마 설계할 때 그렇게 하려다가, 별 문제 없기도해서, prisma한테 맡겼던 부분입니당..

junction table이라고 불리더라구요.
위처럼 manytomany로 만들어지는 테이블들 장점이 ORM에서 편하게 만들어준다는게 큰 장점입니다.

• 사실 ORM없으면 원래 저런 테이블들을 하나하나 만들어줘야하거든요.

이게 단점이 관계에 대한 추가적인 설명을 붙일 수가 없다는 겁니다. 프로필_해시태그라는 관계에 대해서 이 관계가 맺어졌다는 것만 추가할 수 있고, 언제 만들어졌는지, 누가만들었는지에 대한 정보는 저장을 하지 못합니다.
근데 제가 지금 저걸 만들려고하는 이유는 hashtag유효성 검증때문인데요, 카테고리와는 다르게 해시태그는 유저쪽에서 여러개의 해시태그를 예약에 넣을 수 있습니다. 서버측에서는 이 해시태그를 멘토프로필이 들고있는지 검증해야하구요.
멘토프로필의 해시태그는 임의의 N개이고, 유저가 입력한 해시태그도 임의의 N개기때문에 지금 어플리케이션 레벨에서 n_n 으로 돌아갑니다. (사실 예약에 들어가는 해시태그 최대 개수가 5개라서 5_N)

맞아요 최대 5개긴한데, 클라이언트의 요청이 1개일때는 25이고, 클라이언트의 요청이 100개일때는 2500이죠. 근데 저걸 데이터베이스 계층에 던져서 처리하게끔하면 어플리케이션 레벨에서는 부담하는게 적어지겠죵

암튼 테이블 만들어서 처리하면 어플리케이션에서 .every 처럼 이벤트루프 블록하는 방식을 회피할수있어서 그렇습니다