Estoy creando una API RESTful. Me cuesta decidir la mejor manera de diseñar las tablas de mi base de datos en torno a mis recursos.
Inicialmente, pensé que una tabla por recurso sería una buena opción, pero ahora me preocupa que esto resulte en tablas exponencialmente más grandes a medida que avanza la cadena de recursos.
Por ejemplo, imagine que tengo tres recursos: usuarios, clientes, ventas. Los usuarios son suscriptores de mi API, los clientes son los clientes y las ventas son compras realizadas por cada cliente a la cuenta de los usuarios.
Se accede a un recurso de venta de la siguiente manera
GET /users/{userID}/clients/{clientID}/sales/{salesID}Entonces, si hay 10 usuarios, cada uno con 10 clientes, y para cada cliente hay 10 ventas, el tamaño de la tabla aumenta a medida que avanzamos en la cadena de recursos.
Estoy bastante seguro de que SQL puede hacer frente a tablas grandes, pero no estoy seguro de cómo la lectura y la escritura retrasarán las cosas. El ejemplo anterior tal vez no lo ilustra, pero mi API cada vez tendrá más escrituras y lecturas a medida que avancemos en la cadena de recursos. Por lo tanto, tengo el escenario en el que las tablas más grandes de mi base de datos se leerán y escribirán más veces que las tablas más pequeñas.
También será necesario unir tablas antes de ejecutar consultas. La razón es que permito que cada usuario tenga un cliente con el mismo nombre. Para evitar obtener datos incorrectos del cliente, la tabla de usuarios y las tablas de clientes se unen por {userID}. Este es también el caso de las ventas. ¿Unir tablas grandes y ejecutar lecturas y escrituras ralentizará aún más las cosas?