¿Es una buena práctica usar la serialización en PHP para almacenar datos en el DB?

Encontré un comentario interesante en php.net sobre la serialización de datos para guardarlo en la base de datos.

Dice lo siguiente:

¡Por favor! ¡Por favor! ¡Por favor! NO serialice los datos y colóquelos en su base de datos. Serialize se puede usar de esa manera, pero le falta el punto de una base de datos relacional y los tipos de datos inherentes a su motor de base de datos. Hacer esto hace que los datos en su base de datos no sean portátiles, difíciles de leer y puedan complicar las consultas. Si desea que su aplicación sea portable a otros idiomas, por ejemplo, si encuentra que desea usar Java para una parte de su aplicación que tiene sentido usar Java, la serialización se convertirá en un problema en las nalgas. Siempre debe poder consultar y modificar datos en la base de datos sin utilizar una herramienta intermedia de un tercero para manipular los datos que se insertarán.

Me he encontrado con esto muchas veces en mi carrera, hace que sea difícil mantener código, código con problemas de portabilidad y datos que es más difícil migrar a otros sistemas RDMS, nuevos esquemas, etc. También tiene la desventaja adicional de hacerlo complicado para buscar en su base de datos según uno de los campos que ha serializado.

Eso no quiere decir que serialize () sea inútil. No es … Un buen lugar para usarlo puede ser un archivo de caché que contenga el resultado de una operación intensiva de datos, por ejemplo. Hay muchísimos más … Simplemente no abuse de la serialización porque el próximo tipo que se presente tendrá una pesadilla de mantenimiento o migración.

Me gustaría saber si esta es una vista estándar sobre el uso de datos de serialización para fines de DB. Es decir, si es una buena práctica usarlo a veces, o si se debe evitar.

Por ejemplo, recibí instrucciones de usar serializarme recientemente.

En este caso, los datos que tuvimos que guardar en una tabla MySQL fueron los siguientes:

  • Marca de auto.
  • Modelo de auto.
  • Versión del coche
  • Información del coche

Car info era una matriz que representa todas las propiedades de una versión, por lo que era una gran cantidad variable de propiedades (menos de 100 propiedades). Esta matriz fue la que se serializará.

La razón principal por la que me dieron para usar serialize fue la siguiente:

Al ser una gran cantidad de campos, es mejor serializar los datos para mejorar el rendimiento en lugar de crear un campo para cada propiedad o varias tablas.

Personalmente estoy más de acuerdo con el comentario en php.net que con esta última aseveración, pero me gustaría aquí más opiniones calificadas que las mías sobre esto.

Al ser una gran cantidad de campos, es mejor serializar los datos para mejorar el rendimiento en lugar de crear un campo para cada propiedad o varias tablas.

Lo consideraría altamente dependiente del caso de uso. ¿Qué pasa si hay una clase Customer que quiere tener información sobre todos los automóviles que están ejecutando diesel o cualquier otro dato específico para el automóvil (el uso de combustible parece más fácil). Debería obtener todos los automóviles de la base de datos, deserializarlos, verificar la propiedad y conservar la lista con todos los automóviles relevantes para el cliente.

Ejemplo: Tuvimos que mover algunos datos relacionados con la persona de un antiguo CMS de cliente a uno nuevo. En lugar de tener cada atributo bien mapeado en la base de datos, toda la información era una sola cadena en la base de datos anterior. Entonces, en lugar de usar una estructura de base de datos adecuada, tuvimos que hacer muchos regex-foo para convertir nuevamente los datos en una estructura adecuada. Por supuesto, esta fue una tarea costosa (tanto monetaria como de carga de trabajo). En este caso, el problema no era tan grande ya que la cantidad de datos era manejable. Pero imagine el mismo escenario con millones de filas y más que una sola cadena ….

El comentario que publicaste solo habla de las estructuras de datos de la OMI. Y estoy de acuerdo, almacenar estos no es muy bueno ni eficiente. Será mucho más fácil tener un error tipográfico en alguna parte o agregar una propiedad nueva de la que otras partes del idioma no tengan conocimiento. Esto TENDRÁ problemas tarde o temprano.

Por otro lado, el almacenamiento de algunas configuraciones que son más fáciles de portar puede ser una buena opción para serializar datos. Podría argumentar que existen archivos de configuración externos más idóneos para este caso, pero esto dependerá en gran medida del caso / philosophy / customer / …

TL; DR En la mayoría de los casos, usar un esquema apropiado tarde o temprano beneficiará el desarrollo completo, la velocidad y la complejidad (ya que prefiero leer muchas descripciones de tabla en lugar de una cadena enorme y críptica). Puede haber algunos casos de uso donde la serialización de datos sea aceptable, por lo que dar una respuesta definitiva si esta es una buena o mala práctica no es tan fácil y depende mucho.