Структура базы данных SQL для API RESTful

Я создаю RESTful API. Я изо всех сил пытаюсь выбрать лучший способ для создания моих таблиц базы данных вокруг моих ресурсов.

Изначально я думал, что таблица с ресурсом будет хорошим способом, но теперь я беспокоюсь, что это приведет к экспоненциально большим таблицам по мере продвижения по цепочке ресурсов.

Например, представьте, у меня есть три ресурса - пользователи, клиенты, продажи. Пользователи являются подписчиками моего API, клиенты - это пользователи-пользователи, а продажи - это покупки, совершаемые каждым клиентом в учетную запись пользователя.

Ресурс продажи доступен следующим образом

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

Таким образом, если есть 10 пользователей, каждый из которых имеет 10 клиентов, и на каждого клиента приходится 10 продаж, размер таблицы увеличивается по мере продвижения по цепочке ресурсов.

Я вполне уверен, что SQL справится с большими таблицами, но я не уверен, что чтение и запись замедляют работу. Возможно, приведенный выше пример не иллюстрирует это, но мой API будет постепенно записывать и читать дальше по цепочке ресурсов. Поэтому у меня есть сценарий, при котором самые большие таблицы в моей базе данных будут считываться и записываться в большее количество раз, чем меньшие таблицы.

Также необходимо будет объединить таблицы перед выполнением запросов. Причина в том, что я разрешаю каждому пользователю иметь клиента с таким же именем. Чтобы избежать получения неверных данных о клиентах, таблица пользователей и таблицы клиентов объединяются {userID}. Это также относится и к продажам. Замедлится ли объединение больших таблиц и выполнение операций чтения и записи?

Я изо всех сил пытаюсь выбрать лучший способ для создания моих таблиц базы данных вокруг моих ресурсов.

Не.

Проектируйте свой API в соответствии с принципами RESTful , проектируйте свою базу данных в соответствии с принципами нормализации . Одно не должно влиять на другого.

Ваша база данных не должна содержать SaleResourceтаблицу, она должна содержать таблицу Sale(или покупку / заказ). Эта таблица будет включать первичный ключ, который однозначно идентифицирует продажи и внешние ключи для связанных таблиц пользователей и клиентов.

Ваш API REST преобразует запрос ресурса, идентифицируемого по GET /users/{userID}/clients/{clientID}/sales/{salesID}запросу, в соответствующий запрос к базе данных, извлекает строку, создает ресурс, представляющий продажу, и возвращает его клиенту.

Помните, что вы в настоящее время выставляете то, что представляется внутренними идентификаторами базы данных (UserID / ClientId / SalesID), для внешнего мира. Это может быть уместно в вашем случае, но, как правило, <entity>IDчувствуется в RESTful API.

Реляционные базы данных (следовательно, SQL) действительно хороши для поиска одной (или нескольких) строк из огромной таблицы. Для этого нужны индексы. Они также очень хороши в обработке соединений. У вас действительно нет вопросов . Между строк вы в основном спрашиваете о том, как проектировать многопользовательскую базу данных. Я предлагаю вам прочитать Multi-Tenant Data Architecture, прежде чем задавать дополнительные вопросы. Выберите один из шаблонов (отдельная база данных, отдельные схемы совместно используемой базы данных, совместно используемая схема совместно используемой базы данных), и тогда мы не сможем обсудить особенности. Прямо сейчас вы только представляете последнюю модель, но не учитываете плюсы и минусы. Прочитать.

В качестве примечания: вам не нужен user/{userID}URI. Вы знаете арендатора (userID) из информации аутентификации.

Просто добавьте к тому, что уже было сказано здесь - вы можете захотеть построить интерфейс между настоящим API и уровнем вашей базы данных. Это облегчает добавление кеширования и сводных таблиц ...