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?
Las bases de datos relacionales (por lo tanto, SQL) son realmente buenas para localizar una (o pocas) filas de una tabla enorme. Para eso están los índices. También son bastante impresionantes en el manejo de uniones. Realmente no tienes una pregunta . Entre líneas, básicamente se pregunta cómo hacer un diseño de base de datos multiinquilino. Le sugiero que lea la arquitectura de datos de inquilinos múltiples antes de hacer más preguntas. Elija uno de los patrones (base de datos separada, esquemas separados de la base de datos compartida, esquema compartido de la base de datos compartida) y luego podemos discutir detalles. En este momento solo imaginas el último patrón, pero no consideraste los pros y los contras. Leer.
Como nota al margen: no necesita
user/{userID}en el URI. Conoce el inquilino (ID de usuario) de la información de autenticación.fuente
user_idcomo una clave a cada tabla y agregarleft.user_id = right.user_ida las combinaciones relevantes (generalmente, todas). Algunos ORM admiten el alcance del acceso. Y no se deje engañar, sus usuarios son inquilinos, ya que no desea que el usuario 'foo' vea / modifique las ventas de la 'barra' del usuario.Solo para agregar a lo que ya se ha dicho aquí: es posible que desee crear una interfaz entre la API real y su capa de base de datos. Facilita la adición de almacenamiento en caché y tablas de resumen más adelante ...
fuente