RESTful API를위한 SQL 데이터베이스 구조

RESTful API를 작성 중입니다. 리소스를 중심으로 데이터베이스 테이블을 디자인하는 가장 좋은 방법을 결정하기 위해 고심하고 있습니다.

처음에는 리소스 당 테이블을 사용하는 것이 좋지만 이제는 리소스 체인 아래로 테이블이 기하 급수적으로 커질 까 걱정됩니다.

예를 들어 사용자, 고객, 영업이라는 세 가지 리소스가 있다고 가정합니다. 사용자는 내 API의 가입자이고 클라이언트는 사용자 고객이며 판매는 각 클라이언트가 사용자 계정으로 구매 한 것입니다.

판매 리소스는 다음과 같이 액세스됩니다

GET /users/{userID}/clients/{clientID}/sales/{salesID}

따라서 10 명의 사용자가 있고 각각 10 명의 고객이 있고 각 고객에 대해 10 명의 판매가있는 경우, 우리가가는 리소스 체인의 크기가 멀수록 테이블 크기가 커집니다.

SQL이 큰 테이블에 대처할 수 있다고 확신하지만 읽기 및 쓰기로 인해 속도가 느려질 지 확실하지 않습니다. 위의 예는 그것을 설명하지 못할 수도 있지만, 제 API는 점진적으로 더 많은 쓰기와 읽기를 할 것이며 우리가가는 리소스 체인을 더 많이 읽을 것입니다. 따라서 데이터베이스에서 가장 큰 테이블을 작은 테이블보다 여러 번 읽고 쓰는 시나리오가 있습니다.

쿼리를 실행하기 전에 테이블을 조인해야합니다. 그 이유는 각 사용자가 같은 이름의 클라이언트를 가질 수 있기 때문입니다. 잘못된 클라이언트 데이터를 얻지 않기 위해 users 테이블과 clients 테이블은 {userID}로 조인됩니다. 이것은 또한 판매의 경우입니다. 큰 테이블을 결합하고 읽기 및 쓰기를 실행하면 속도가 느려질까요?

리소스를 중심으로 데이터베이스 테이블을 디자인하는 가장 좋은 방법을 결정하기 위해 고심하고 있습니다.

하지마

RESTful 원칙 에 따라 API를 설계하고 정규화 원칙 에 따라 데이터베이스를 설계하십시오 . 하나는 다른 것에 영향을 줄 필요가 없습니다.

데이터베이스는 SaleResource테이블을 포함하지 않아야하고, 테이블은 Sale(또는 구매 / 주문) 테이블을 포함해야합니다 . 이 테이블에는 관련 사용자 및 고객 테이블에 대한 판매 및 외래 키를 고유하게 식별하는 기본 키가 포함됩니다.

REST api는 식별 한 자원에 대한 요청을 GET /users/{userID}/clients/{clientID}/sales/{salesID}해당 데이터베이스 쿼리로 변환하고, 행을 검색하며, 판매를 나타내는 자원을 구성하고이를 클라이언트로 리턴합니다.

현재 내부 데이터베이스 식별자 (UserID / ClientId / SalesID)로 보이는 것을 외부에 공개하고 있습니다. 귀하의 경우에는 적절할 수 있지만 일반적으로 <entity>IDRESTful API에서 느낍니다.

관계형 데이터베이스 (따라서 SQL)는 거대한 테이블에서 하나 또는 몇 개의 행을 찾는 데 정말 좋습니다. 이것이 색인의 대상입니다. 또한 조인 처리에 매우 뛰어납니다. 당신은 실제로 질문이 없습니다 . 줄 사이에서 기본적으로 다중 테넌트 데이터베이스 디자인을 수행하는 방법을 묻습니다. 추가 질문을하기 전에 다중 테넌트 데이터 아키텍처 를 읽어보십시오 . 패턴 (개별 데이터베이스, 공유 데이터베이스 별도 스키마, 공유 데이터베이스 공유 스키마) 중 하나를 선택한 다음 세부 사항에 대해 논의합니다. 지금은 마지막 패턴 만 구상했지만 장단점은 고려하지 않았습니다. 읽어봐

참고로 user/{userID}URI에 필요하지 않습니다 . 인증 정보에서 테넌트 (userID)를 알고 있습니다.

여기에 이미 언급 된 내용에 추가하기 위해 실제 API와 데이터베이스 계층 사이에 인터페이스를 구축 할 수 있습니다. 캐싱 및 요약 테이블을 쉽게 추가 할 수 있습니다.