Struktura bazy danych SQL dla RESTful API

Tworzę interfejs API RESTful. Próbuję wybrać najlepszy sposób zaprojektowania tabel bazy danych wokół moich zasobów.

Początkowo wydawało mi się, że dobrym pomysłem byłby wybór tabeli na zasób, ale teraz martwię się, że spowoduje to wykładniczo większe tabele, im dalej w dół łańcucha zasobów.

Wyobraź sobie na przykład, że mam trzy zasoby - użytkowników, klientów, sprzedaż. Użytkownicy są subskrybentami mojego interfejsu API, klienci są klientami użytkowników, a sprzedaż to zakupy dokonywane przez każdego klienta na koncie użytkownika.

Dostęp do zasobów sprzedaży można uzyskać w następujący sposób

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

Więc jeśli jest 10 użytkowników, każdy z 10 klientami, a dla każdego klienta występuje 10 sprzedaży, rozmiar tabeli staje się większy w miarę, jak idziemy w dół łańcucha zasobów.

Jestem całkiem pewien, że SQL poradzi sobie z dużymi tabelami, ale nie jestem pewien, w jaki sposób odczyt i zapis spowolnią. Powyższy przykład może tego nie ilustruje, ale mój interfejs będzie stopniowo zapisywał i odczytywał kolejne etapy łańcucha zasobów. Dlatego mam scenariusz, w którym największe tabele w mojej bazie danych będą czytane i zapisywane więcej razy niż mniejsze tabele.

Konieczne będzie także dołączenie do tabel przed uruchomieniem zapytań. Powodem jest to, że pozwalam każdemu użytkownikowi mieć klienta o tej samej nazwie. Aby uniknąć uzyskania niewłaściwych danych klienta, do tabeli użytkowników i tabel klientów dołącza {identyfikator użytkownika}. Dotyczy to również sprzedaży. Czy dołączanie do dużych tabel i uruchamianie odczytów i zapisów jeszcze bardziej spowolni?

Próbuję wybrać najlepszy sposób zaprojektowania tabel bazy danych wokół moich zasobów.

Nie rób

Zaprojektuj interfejs API zgodnie z zasadami RESTful , zaprojektuj bazę danych zgodnie z zasadami normalizacji . Jedno nie ma wpływu na drugie.

Twoja baza danych nie powinna zawierać SaleResourcetabeli, powinna zawierać tabelę Sale(lub zakupu / zamówienia). Ta tabela będzie zawierała klucz podstawowy, który jednoznacznie identyfikuje sprzedaż i klucze obce do powiązanych tabel użytkowników i klientów.

Interfejs API REST przetłumaczy zapytanie o zasób wskazany przez GET /users/{userID}/clients/{clientID}/sales/{salesID}na odpowiednie zapytanie do bazy danych, pobierze wiersz, zbuduje zasób reprezentujący sprzedaż i zwróci go klientowi.

Pamiętaj, że obecnie ujawniasz świat zewnętrzny, co wydaje się wewnętrznymi identyfikatorami bazy danych (UserID / ClientId / SalesID). Może być odpowiednie w twoim przypadku, ale ogólnie <entity>IDczuje się źle w RESTful API.

Relacyjne bazy danych (stąd SQL) są naprawdę dobre w lokalizowaniu jednego (lub kilku) wierszy z ogromnej tabeli. Do tego służą indeksy. Są również całkiem niesamowici w obsłudze połączeń. Naprawdę nie masz pytania . Pomiędzy wierszami w zasadzie pytasz o sposób zaprojektowania bazy danych dla wielu dzierżawców. Sugeruję przeczytanie architektury danych dla wielu najemców przed zadaniem dalszych pytań. Wybierz jeden ze wzorów (oddzielna baza danych, osobne schematy współużytkowanej bazy danych, wspólny schemat współużytkowanej bazy danych), a następnie omówimy szczegóły. W tej chwili wyobrażasz sobie tylko ostatni wzór, ale nie wziąłeś pod uwagę zalet i wad. Zaznajomić się.

Na marginesie: nie potrzebujesz user/{userID}w URI. Znasz dzierżawcę (ID użytkownika) z informacji uwierzytelniających.

Aby dodać do tego, co już tu powiedziano - możesz zbudować interfejs między rzeczywistym interfejsem API a warstwą bazy danych. Ułatwia to dodawanie tabel buforowania i tabel podsumowań ...