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

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

Спочатку я хоч таблиця на один ресурс був би хорошим способом, але зараз я переживаю, що це призведе до експоненціально більших таблиць далі вниз по ланцюгу ресурсів, який ви йдете.

Наприклад, уявіть, що у мене є три ресурси - користувачі, клієнти, продажі. Користувачі - абоненти моїх api, клієнти - це клієнти, а продажі - це покупки, які здійснює кожен клієнт на обліковий запис користувачів.

До ресурсу продажу звертається наступним чином

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

Отже, якщо є 10 користувачів, кожен з 10 клієнтів, і для кожного клієнта 10 продажів, розмір таблиці збільшується, чим далі ми рухаємося вниз по ланцюжку ресурсів.

Я досить впевнений, що SQL може впоратися з великими таблицями, але я не впевнений, як читання і запис сповільнить справи. Наведений вище приклад, можливо, не ілюструє це, але мій api буде прогресивно більше записувати і читати далі вниз по ресурсному ланцюгу, який ми йдемо. Тому у мене є сценарій, коли найбільші таблиці в моїй базі даних будуть читатися і записуватися більше разів, ніж менші таблиці.

Також потрібно буде з'єднати таблиці перед запуском запитів. Причина в тому, що я дозволяю кожному користувачеві мати клієнт з тим же ім’ям. Щоб уникнути отримання помилкових даних клієнта, до таблиці користувачів і таблиць клієнтів приєднується {userID}. Це стосується і продажів. Чи приєднуються до великих таблиць і працювати читає і записує повільні речі далі?

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

Не варто.

Створюйте свій API за принципами RESTful , розробляйте базу даних відповідно до принципів нормалізації . Одному не потрібно впливати на іншого.

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

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

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

Реляційні бази даних (отже, SQL) дійсно добре знаходять один (або кілька) рядків з величезної таблиці. Для цього потрібні індекси. Вони також дуже приголомшливі в обробці приєднань. У вас насправді не виникає питання . Між рядками ви в основному запитуєте, як зробити дизайн баз даних для багатьох орендарів. Пропоную прочитати архітектуру даних для багатьох орендарів, перш ніж задавати додаткові запитання. Виберіть один із шаблонів (окрема база даних, окремі схеми спільної бази даних, спільна схема спільної бази даних), а потім ми обговоримо особливості. Зараз ви лише передбачаєте останню схему, але не враховували плюси та мінуси. Прочитайте.

Як бічна примітка: вам не потрібен user/{userID}URI. Ви знаєте орендаря (userID) з інформації про автентифікацію.

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