Strutture dati del database per RESTful api

1

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?

    
posta Gaz_Edge 18.02.2013 - 16:17
fonte

1 risposta

1

Non vedo esattamente dove sarebbe diverso senza REST. Questo è un compito piuttosto normale per un database e query di questo tipo vengono eseguite in ogni momento. La cosa principale da fare è ovviamente avere indici sui campi id.

Una volta che questo funziona per un po 'di tempo, avrai molte vendite e dovrai effettuare una query per le vendite non solo per utente / cliente, ma limitarti a un determinato intervallo di date (come il mese scorso). Anche in questo caso non dovrebbe esserci alcun problema, supponendo di avere indici su quei campi.

Un punto debole nella progettazione (sebbene possa dipendere dal caso d'uso) è che un singolo client può funzionare solo con un utente specifico. Penserei che alcuni di quegli utenti sono in vacanza una volta tanto ei clienti possono acquistare da utenti diversi per questo (o altri) motivi. Quindi forse la tabella delle vendite dovrebbe avere userID e clientID.

    
risposta data 18.02.2013 - 16:26
fonte

Leggi altre domande sui tag