Sto creando un'API RESTful. Sto lottando per decidere il modo migliore per progettare le mie tabelle di database attorno alle mie risorse.
Inizialmente, penso che un tavolo per risorsa sarebbe un buon modo per andare, ma ora sono preoccupato che questo si tradurrà in tabelle esponenzialmente più grandi più in basso lungo la catena di risorse.
Ad esempio, immagina di avere tre risorse: utenti, clienti, vendite. Gli utenti sono abbonati alla mia API, i clienti sono i clienti degli utenti e le vendite sono acquisti effettuati da ciascun cliente sull'account degli utenti.
Si accede a una risorsa di vendita come segue
GET /users/{userID}/clients/{clientID}/sales/{salesID}
Quindi se ci sono 10 utenti, ciascuno con 10 clienti e per ogni cliente ci sono 10 vendite, le dimensioni della tabella diventano più grandi più in basso lungo la catena di risorse che andiamo.
Sono abbastanza sicuro che SQL possa far fronte a tabelle di grandi dimensioni, ma non sono sicuro che la lettura e la scrittura rallenteranno le cose. L'esempio sopra, forse, non lo illustra, ma la mia API avrà progressivamente più scritture e letture più in basso lungo la catena di risorse. Ho quindi lo scenario in cui le tabelle più grandi del mio database saranno lette e scritte più volte rispetto alle tabelle più piccole.
Sarà inoltre necessario unire le tabelle prima di eseguire le query. Il motivo è che autorizzo ogni utente ad avere un client con lo stesso nome. Per evitare di ottenere dati client errati, la tabella degli utenti e le tabelle dei client sono uniti da {userID}. Questo è anche il caso delle vendite. Riuscirà a unire tabelle di grandi dimensioni e a eseguire letture e scrivere ulteriormente le cose?