api 데이터 모델링 시, pandantic?

강의를 보고 문서를 보고 정리하는 과정 중에 헷갈리는 점이 있어서 질문 드려봅니다.

저희 코드에서 schema안에 response , request 의 스키마는pydantic의 basemodel로 설계가 되어있고 ,

database Orm에는 유저 모델과 todo를 만들었는데, 이 부분은 sql alcemy의 base declaritve를 사용한걸로 기억합니다.

(모델 폴더와 스키마 폴더가 헷갈립니다..)

백엔드 설계를 할때, 데이터 구조 그리고 erd등 관계도 설정 후에 모델링을 fast api로 할때는 , 저희 강의 때 한 것처럼 orm안에 해준 것처럼 하는 방식일까요?
pydantic으로 schema(폴더명 때문에 헷갈리는 부분일 수도.)에서는 단순히 req,res 에 있어서 타입을 검증하기 위한 모델을 설계한 것이라고 보면 될까요?

강의를 듣고, 실제로 백엔드 api 만들어서 프로젝트 구성해보려 하는 과정에서 질문이 있어서 드려봅니다.

1 to many는 아래처럼 하고 , m to m인 경우도 아래 와 비슷한 형식으로 모델링을 하는 걸까요? 강의에서는 맛보기로 간단하게 소개형식이지만 실제로 프로젝트를 한다고 했을땐, 어떻게 작성하는지 궁금합니다.
```
user_id = Column(Integer, ForeignKey("user.id"))
```
Repository 는 mvc의 컨트롤러라고 생각하면 될까요?
모델링 할때, SQLModel로 하는 방법과 강의에서 나온 Base상속방법의 차이는 무엇일까요? 구글링해도 잘 나오지 않네요.. 둘다 상관없다면, 어떠한 것이 선호가 되는지 왜 강의에서는 base상속을 했는지 이유가 있으실까요? SQL Model도 fastapi 저자가 만든 것인고 pydantic기반이라고 들었습니다.
번외로..
저희가 배운걸로는 declartive 를 상속받는데, 아래와 같은 형식으로도 모델링을 하기도 하나요?

from sqlmodel import SQLModel, Field

class User(SQLModel, table = True):
    nickname: str = Field(primary_key = True)
    password: str

안녕하세요. 질문에 답변 드립니다 :D

schema, model과 같은 용어는 범용적으로 쓰이기 때문에 충분히 헷갈리실 수 있을 것 같습니다.

또 같은 용어라도 개발자나 회사에 따라 달리 부르는 경우도 종종 있는 것 같습니다.

따라서 용어 보다는 해당 객체가 어떤 역할을 하는지를 프로젝트 내에서 잘 정의하고 이해하는 것이 중요할 것 같습니다.

본 강의에서는 요청과 응답의 데이터를 모델링하여 일정하게 사용하기 위해서(또 FastAPI의 OpenAPI와 SwaggerUI 기능을 활용하기 위해서) schema 디렉토리 아래에 request와 response를 모델링 하였습니다.

이어지는 질문에도 답변 드립니다.

1. 데이터베이스 테이블 모델링은 sqlalchemy를 이용하시면 됩니다.

2-1. (pydantic 관련) 맞습니다. 앞서 설명드린 것처럼 FastAPI를 이용할 때 Pydantic의 기능을 최대한 활용하기 위함입니다.

2-2. (테이블 모델링 관련) 데이터베이스 테이블 모델링에서 many to many를 구현할 때는 보통 중계 테이블을 이용하여 총 3개의 테이블을 통해 데이터를 모델링합니다. 예를 들어, A와 B를 many to many로 모델링 한다면, 중계 테이블인 C를 두어서 A와 C를 1:N으로 모델링하고, C와 B를 N:1로 모델링하는 방식으로 구현할 수 있습니다. sqlalchemy를 이용하여 many to many를 구현하는 자세한 방법은 문서를 참고 부탁드립니다.

https://docs.sqlalchemy.org/en/20/orm/basic_relationships.html#many-to-many

3. 아닙니다. Repository를 데이터 조회를 추상화하는 컴포넌트로 MVC 패턴에 해당하지 않습니다. MVC 패턴의 Controller는 FastAPI의 router에 가깝습니다.

4. SQLModel은 말씀하신 것처럼 FastAPI와 쉽게 연동하기 위해 만들어진 ORM 라이브러리입니다. 다만 SQLModel 모델 역시 내부에는 sqlalchemy를 사용하고 있습니다. 강의에서 SQLModel을 사용하지 않은 이유는 SQLModel은 만들어진지 얼마 되지 않은 라이브러리이기 때문에 충분히 검증되지 않았고, 데이터베이스를 다루기 위해 지원하는 기능이 아직은 제한적입니다. 이에 반해 sqlalchemy는 python 진영에서 매우 오랫동안 사용되는 라이브러리이기 때문에 지원하는 기능이 더 많고, 관련된 자료를 찾기도 수월합니다.

5. 네, SQLModel을 사용할 때 테이블을 모델링하는 방법입니다. 라이브러리 코드를 확인해보니 SQLModel 역시 내부적으로는 sqlalchemy의 declarative base 방식을 사용하고 있습니다. https://github.com/tiangolo/sqlmodel/blob/088164ef2aa30a21a168f511a998f85c469bba1c/sqlmodel/main.py#L209C58-L209C58

인프런 커뮤니티 질문&답변