Prácticas recomendadas para modificar tablas de base de datos

Última actualización: 15 de julio de 2024

Creado para:

  • Experimentado
  • Desarrollador

Este artículo proporciona prácticas recomendadas para modificar tablas de base de datos creadas por Adobe Commerce o módulos de terceros. Comprender cuándo y cómo modificar tablas de forma eficaz ayuda a garantizar la viabilidad y estabilidad a largo plazo de su plataforma de comercio.

Migrar desde Magento 1 y otras plataformas de comercio electrónico, o trabajar con módulos del mercado Adobe Commerce, puede requerir agregar y guardar datos adicionales. Su primer instinto podría ser agregar una columna a una tabla de la base de datos o ajustar una existente. Sin embargo, solo debe modificar una tabla principal Adobe Commerce (o una tabla de proveedores de terceros) en situaciones limitadas.

Por qué el Adobe recomienda evitar las modificaciones

El motivo principal para evitar la modificación de las tablas principales es que Adobe Commerce incluye una lógica subyacente que contiene consultas SQL sin procesar. Los cambios en la estructura de la tabla pueden producir efectos adversos inesperados que son difíciles de solucionar. El cambio también puede afectar a las operaciones de DDL (lenguaje de definición de datos), lo que provoca efectos inesperados e impredecibles en el rendimiento.

Otro motivo para evitar cambiar la estructura de la tabla de la base de datos es que los cambios pueden causar problemas si el equipo de desarrollo principal o los desarrolladores de terceros cambian la estructura de sus tablas de base de datos. Por ejemplo, hay algunas tablas de base de datos principales que tienen una columna denominada additional_data. Siempre ha sido un tipo de columna text. Sin embargo, por motivos de rendimiento, el equipo principal podría cambiar la columna a longtext. Este tipo de columna es un alias para JSON. Al convertir a este tipo de columna, se agregan mejoras de rendimiento y capacidad de búsqueda a esa columna, que no existe como tipo text. Puede obtener más información sobre este tema en Tipo de datos JSON.

Saber cuándo guardar o quitar datos

El Adobe recomienda determinar primero si es necesario guardar estos datos. Si mueve datos de un sistema heredado, cualquier dato que pueda eliminar le ahorrará tiempo y esfuerzo durante la migración. (Hay formas de archivar los datos si es necesario acceder a ellos más adelante). Para ser un buen administrador de la aplicación y el rendimiento, está bien retar una solicitud para guardar datos adicionales. Su objetivo es garantizar que guardar los datos sea un requisito para satisfacer una necesidad empresarial que no se puede rellenar de otra manera.

Datos heredados

Si el proyecto contiene datos heredados, como pedidos antiguos o registros de clientes, considere un método de búsqueda alternativo. Por ejemplo, si la empresa requiere acceso a los datos solo para referencia ocasional, considere implementar una búsqueda externa de la base de datos antigua alojada fuera de la plataforma de comercio en lugar de migrar los datos antiguos a Adobe Commerce.

Esta situación requeriría que la base de datos se migrara a un servidor, ofreciendo ya sea una interfaz web para leer los datos, o quizás capacitación en el uso de MySQL Workbench o herramientas similares. Excluir estos datos de la nueva base de datos acelera la migración, ya que permite al equipo de desarrollo centrarse en el nuevo sitio en lugar de solucionar los problemas de migración de datos.

Otra opción relacionada para mantener los datos externos al comercio pero que le permite utilizarlos en tiempo real sería aprovechar otras herramientas, como GraphQL mesh. Esta opción combina diferentes fuentes de datos y las devuelve como una sola respuesta.

Por ejemplo, puede stitch agrupar pedidos antiguos de una base de datos externa, tal vez el sitio antiguo del Magento 1 que se ha retirado del mercado. A continuación, utilizando GraphQL mesh, muéstrelos como parte del historial de pedidos de los clientes. Estos pedidos antiguos se pueden combinar con los pedidos del entorno actual Adobe Commerce.

Para obtener más información sobre el uso de la malla de API con GraphQL, consulte Qué es la malla de API) y Puerta de enlace de GraphQL Mesh.

Migración de datos heredados con atributos de extensión

Si determina que los datos heredados requieren migración o que los nuevos datos deben guardarse en Adobe Commerce, Adobe recomienda usar atributos de extensión. El uso de atributos de extensión para guardar datos adicionales ofrece las siguientes ventajas:

  • Puede controlar los datos que se mantienen y la estructura de la base de datos, que garantiza que los datos se guarden con el tipo de columna correcto y los índices adecuados.
  • La mayoría de las entidades de Adobe Commerce admiten el uso de atributos de extensión.
  • Los atributos de extensión son un mecanismo independiente del almacenamiento que proporciona la flexibilidad para guardar los datos en la ubicación óptima para su proyecto.

Dos ejemplos de ubicaciones de almacenamiento son las tablas de base de datos y Redis. Las cosas clave que hay que tener en cuenta al elegir una ubicación son si la ubicación presenta una complejidad adicional o afecta al rendimiento.

Considerar otras alternativas

Como desarrollador, es vital considerar siempre el uso de herramientas fuera de su entorno de Adobe Commerce, como GraphQL mesh y Adobe App Builder. Estas herramientas pueden ayudarle a conservar el acceso a los datos, pero no afectan a la aplicación principal de comercio ni a sus tablas de base de datos subyacentes. Con este enfoque, expone sus datos a través de una API. A continuación, agregue una fuente de datos a la configuración de App Builder. Con GraphQL Mesh, puedes combinar esas fuentes de datos y producir una única respuesta como se menciona en datos heredados.

Para obtener más información sobre GraphQL mesh, consulte GraphQL Mesh Gateway. Para obtener información acerca del Adobe App Builder, consulte Presentación de App Builder.

Modificación de una tabla principal o de una tabla de terceros

Si decide almacenar datos modificando una tabla de base de datos de módulo principal Adobe Commerce o de terceros, siga las siguientes directrices para minimizar el impacto en la estabilidad y el rendimiento.

  • Agregue solo las columnas nuevas.
  • Nunca modifique el valor type de una columna existente. Por ejemplo, no cambie un integer por un varchar para satisfacer su caso de uso único.
  • Evite añadir columnas a tablas de atributos EAV. Estas tablas ya están sobrecargadas de lógica y responsabilidad.
  • Antes de ajustar una tabla, determine su tamaño. Cambiar tablas grandes afecta a la implementación, lo que puede causar minutos u horas de retraso cuando se aplican cambios.

Prácticas recomendadas para modificar una tabla de base de datos externa

Adobe recomienda seguir estos pasos cuando agregue una columna a una tabla de la base de datos principal o a una tabla de terceros:

  1. Cree un módulo con un nombre en el área de nombres que represente lo que está actualizando.

    Por ejemplo: app/code/YourCompany/Customer

  2. Cree los archivos apropiados para habilitar el módulo (consulte Crear un módulo.

  3. Cree un archivo denominado db_schema.xml en la carpeta etc y realice los cambios correspondientes.

    Si corresponde, genere un archivo de db_schema_whitelist.json. Vea Esquema declarativo para obtener más información.