Optimización en Plataformas Multi-inquilino: Eliminación de ID de Compañía Redundante
En la Plataforma Reimpact, la gestión de datos para múltiples inquilinos es un pilar fundamental de nuestra arquitectura. Para garantizar la seguridad y el aislamiento de la información, utilizamos esquemas de base de datos dedicados por inquilino, una estrategia que simplifica enormemente el manejo de datos segregados.
Recientemente, identificamos una redundancia en cómo se manejaban las consultas relacionadas con el proceso de homologación, específicamente en la tabla packaging_homologation_matches y en la replicación de recetas. Aunque estas tablas ya operan dentro de un esquema de inquilino aislado (lo que intrínsecamente proporciona el alcance de company_id), se seguía utilizando explícitamente la columna company_id en las operaciones de inserción, consulta y eliminación.
Esta práctica resultaba en un filtrado o especificación de datos innecesarios, ya que el aislamiento a nivel de esquema ya garantiza que solo los datos del inquilino correspondiente sean accesibles. La presencia de company_id en estas consultas no solo era redundante, sino que también podía llevar a confusiones o complejidades innecesarias en el código.
Para optimizar y alinear mejor nuestras operaciones de base de datos con nuestra arquitectura multi-inquilino, hemos implementado una corrección que elimina el uso de company_id en las consultas que afectan a la tabla packaging_homologation_matches. Esto incluye procesos críticos como ProcessHomologationChunk, DispatchHomologationPreviewBatch, ExecuteHomologation y HomologationTool, así como en la replicación de recetas para inquilinos.
Este cambio simplifica las consultas y el mantenimiento del código, eliminando una fuente potencial de errores y haciendo que nuestras operaciones de datos sean más eficientes y coherentes con los principios de nuestra arquitectura. Ahora, el sistema depende exclusivamente del aislamiento de esquema para el scoping, lo que clarifica la intención y reduce la carga en la base de datos.
Consideremos un ejemplo simplificado en PHP:
// Antes: Consulta con company_id redundante en un esquema ya aislado
// Esto es conceptual, asumiendo que ya estamos en el contexto del esquema del inquilino
$tenantId = 123;
$dataId = 456;
$companyId = 789; // Este valor ya está implicado por el esquema
$queryBefore = "SELECT * FROM app_config.homologation_matches WHERE data_id = :dataId AND company_id = :companyId;";
// Ejecución con parámetros: ['dataId' => $dataId, 'companyId' => $companyId]
// Después: Consulta optimizada, confiando en el aislamiento del esquema
// El esquema 'app_config' ya pertenece a un inquilino específico
$queryAfter = "SELECT * FROM app_config.homologation_matches WHERE data_id = :dataId;";
// Ejecución con parámetros: ['dataId' => $dataId]
Este ajuste, aunque aparentemente pequeño, refuerza la robustez de nuestra plataforma y asegura que cada componente se adhiera a la arquitectura diseñada para la eficiencia y la escalabilidad.
