Traemos la mejor solución que descubrimos en línea. Nosotros esperamos que te resulte de mucha ayuda y si puedes comentarnos alguna mejora siente la libertad de hacerlo..
Solución:
Como dice GWW en los comentarios, si necesita consultar las cosas de esta manera, realmente debería considerar almacenar estos datos como algo más que un gran ole-string (que es lo que has serializado array es).
Si eso no es posible (o simplemente es perezoso), puede usar el hecho de que el serializado array es solo un gran-ole-stringy descubra una cláusula LIKE para encontrar registros coincidentes. La forma en que PHP serializa los datos es bastante fácil de entender (pista: esos números indican la longitud de las cosas).
Ahora, si su serializado array es bastante complejo, esto se descompondrá rápidamente. Pero si es un piso arraydeberías poder hacerlo.
Por supuesto, usará LIKE ‘%…%’, por lo que no obtendrá ayuda de ningún indicador y el rendimiento será muy bajo.
Es por eso que la gente sugiere que almacene esos datos de manera normalizada, si necesita consultar “dentro” de ellos.
Si tiene el control del modelo de datos, el relleno de datos serializados en la base de datos lo morderá a la larga casi siempre. Sin embargo, muchas veces uno no tener control sobre el modelo de datos, por ejemplo, cuando se trabaja con determinados sistemas de gestión de contenido de código abierto. Drupal pega un lote de datos serializados en columnas de contenedor en lugar de un modelo adecuado. Por ejemplo, ubercart tiene una columna de “datos” para todos sus pedidos. Los módulos contribuidos deben adjuntar datos a la entidad de pedido principal, por lo que, por conveniencia, los agregan al blob serializado. Como tercero en esto, todavía necesito una forma de acceder a algunos de los datos incluidos allí para responder algunas preguntas.
a:4:s:7:"cc_data";s:112:"6"CrIPY2IsMS1?blpMkwRj[XwCosb]gl[email protected]";s:7:"cc_txns";a:1:s:10:"references";a:1:i:0;a:2:s:4:"card";s:4:"3092";s:7:"created";i:1296325512;s:13:"recurring_fee";b:1;s:12:"old_order_id";s:2:"25";
¿Ves ese ‘old_order_id’? Eso es key Necesito averiguar de dónde proviene este pedido recurrente, pero dado que no todos usan el módulo de pedidos recurrentes, no hay un lugar adecuado para almacenarlo en la base de datos, por lo que el desarrollador del módulo optó por guardarlo en esa tabla de contenedores.
Mi solución es usar algunos SUBSTRING_INDEX específicos para eliminar datos insignificantes hasta que haya esculpido el resultado string en la piedra preciosa de datos de mis deseos. Luego agrego una cláusula HAVING para encontrar todas esas coincidencias, así:
SELECT uo.*,
SUBSTRING_INDEX(
SUBSTRING_INDEX(
SUBSTRING_INDEX( uo.data, 'old_order_id' , -1 ),
'";', 1),
'"',-1)
AS `old order id`
FROM `uc_orders AS `uo`
HAVING `old order id` = 25
El SUBSTRING_INDEX más interno me da todo más allá del old_order_id, y los dos externos limpian el resto.
Esta piratería complicada no es algo que desee en el código que se ejecuta más de una vez, sino más bien una herramienta para obtener los datos de una tabla sin tener que recurrir a escribir un script php.
Tenga en cuenta que esto pudo simplificarse a meramente
SELECT uo.*,
SUBSTRING_INDEX(
SUBSTRING_INDEX( uo.data, '";' , 1 ),
'"',-1)
AS `old order id`
FROM `uc_orders` AS `uo`
HAVING `old order id` = 25
pero eso solo funcionaría en este caso específico (el valor que quiero está al final del blob de datos)
Entonces quieres usar MySQL para buscar en un PHP array que ha sido serializado con el comando serialize y almacenado en un campo de base de datos? Mi primera reacción sería: Dios mío. Mi segunda reacción sería: ¿por qué? los sensato lo que hay que hacer es:
- recuperar el array en PHP, deserializarlo y buscar en él
- Olvídese de almacenar los datos en MySQL como serializados y guárdelos como una tabla regular e indexarlos para una búsqueda rápida
Elegiría la segunda opción, pero no conozco su contexto.
Por supuesto, si realmente quisieras, podrías probar algo con SUBSTRING u otra función de MySQL e intente manipular el campo, pero no veo por qué querría hacerlo. Es engorroso y sería un truco desagradable e innecesario. Por otro lado, es un rompecabezas, y a la gente aquí le suelen gustar los rompecabezas, así que Si de verdad quieres luego publique el contenido de su campo y podemos darle una oportunidad.