Cómo diseñar consultas UPDATE, REMOVE de una base de datos y una API desde una vista arbitraria?
Digamos que tengo una base de datos simple como la siguiente:
Tabla 1. Car_registration_id (PK) | Propietario | Fecha de registro
Tabla 2. Car_serial_number (PK) | Modelo de coche | Car_registration_id (FK)
Un usuario realiza consultas para recuperar vistas arbitrarias como las siguientes (también pueden ser otras vistas diferentes).
Esta vista no tiene una columna identificadora
Vista 1. Modelo de coche | Propietario
Esta vista tiene al menos 1 columna identificadora
Vista 2. Car_registration_id | Car_serial_number | Propietario | Modelo de coche
Las restricciones son:
- El frontend no conoce los esquemas de la base de datos. Solo envía solicitudes a través de una API proporcionada.
- Todo el procesamiento se queda en el backend.
La pregunta es, ¿cuál es una estrategia/patrón para diseñar consultas junto con puntos finales de API en los que un usuario puede simplemente ir a una tabla de vista en el frontend, modificar cualquier número de celdas (SOLO ACTUALIZAR o ELIMINAR), y luego reflejar los cambios en la base de datos? La modificación se puede aplicar a diferentes tablas, columnas y filas a la vez. En mi caso de uso, la base de datos puede tener más de 10 tablas, por lo que el número de columnas no es pequeño.
Actualmente estoy pensando en 2 enfoques, pero no parecen funcionar:
- Crear puntos finales para todas las combinaciones posibles, tanto para solicitudes con como sin información de columnas identificadoras. Esto funcionará, pero a costa de una cantidad exponencial de código para mantener, por lo que no es razonable.
- Enviar las columnas identificadoras al cliente sin importar si aparecen en la vista o no (solo almacenar en memoria). Luego, utilizar toda la información de la solicitud del cliente para construir las consultas respectivamente. Sin embargo, como un usuario puede modificar una cantidad arbitraria de columnas, esto lleva a una condición/ combinación compleja para construir una consulta, por lo que también es un problema. Además, ¿cómo separar los puntos finales lógicamente en este caso de uso?
Estoy usando TypeORM, pero también está bien usar SQL sin procesar. ¡Cualquier ayuda es apreciada!
davy.ai
Una posible estrategia para diseñar consultas y puntos finales de API para el escenario dado es hacer uso de una capa intermedia que actúe como puente entre el front-end y el back-end. Esta capa intermedia se puede diseñar para manejar todo el acceso a la base de datos, consultas y modificaciones basadas en las solicitudes que recibe del front-end a través de la API.
La capa intermedia puede tener puntos finales predefinidos para cada vista que permita al usuario modificar cualquier número de celdas. Por ejemplo, si un usuario desea modificar una vista que tiene columnas de identificación, la capa intermedia puede recibir una solicitud que especifique los valores de las columnas de identificación junto con los valores modificados. La capa intermedia puede construir una consulta utilizando las columnas de identificación y actualizar los valores en las filas correspondientes en consecuencia.
Para manejar casos en los que el usuario ha modificado valores que no pertenecen a columnas de identificación, la capa intermedia puede utilizar una tabla temporal que almacene los valores modificados junto con un identificador único que represente las filas que se están modificando. La capa intermedia puede utilizar las columnas de identificación para actualizar la tabla temporal y luego utilizar la información de la tabla temporal para actualizar las tablas reales con los valores modificados. Este enfoque puede manejar modificaciones que afectan a múltiples tablas también.
Otra estrategia posible es usar SQL dinámico para construir consultas basadas en la solicitud del usuario. El front-end puede enviar una solicitud que especifique la vista, los valores modificados y las columnas de identificación (si las hay). La capa intermedia puede construir dinámicamente una consulta SQL basada en la solicitud del usuario y ejecutarla en la base de datos. Este enfoque puede manejar modificaciones que afectan a múltiples tablas y también se puede utilizar para cubrir escenarios en los que el usuario modifica columnas que no son de identificación.
En general, es importante asegurarse de que la capa intermedia maneje todo el acceso a la base de datos y las consultas, y que los puntos finales de la API solo expongan la funcionalidad requerida por el front-end. Esto puede ayudar a mantener la seguridad e integridad de los datos, y también puede hacer que el código sea más mantenible y escalable.