| Respuesta: consulta a mi base de datos mostrando los 3 ultimos años
La verdad, no estoy seguro de por donde empezar, porque tu problema es algo más complicado de lo esperado, especialmente si la base de datos ya está cargada con muchos registros en las tablas...
Mira, a primera vista, pensé que el único problema es que había una errónea selección de tipos de dato en tus columnas, e incluso que necesitaríamos usar alguna que otra función para manejar la cosa.
Pero cuando vi que mencionabas que en el mismo campo "p_ano", contiene datos como "2012,2010,2009,2008", la cosa se puso espesa, y más aún al percatarme de que "p_meses" tiene un ancho de 8000 caracteres, caí en cuenta que está base de datos es simple... como decirlo... Trash data.
Empecemos por el principio: Si no puedes modificar la estructura de las tablas para corregir los desmanes que tiene la base, simplemente ignora todo el resto del post, y busca alguna solución por el lado de la programación. El SQL no te va a ayudar, al menos no de una forma sencilla.
Explico esto: Has creado para esos dos datos, campos multivaluados, que no solamente están prohibidos en el modelo de Entidad-Relación (y por extensión en las bases de datos relacionales), sino que generan enormes problemas para las consultas, precisamente como el que te enfrentas.
El concepto de mes pagado (o cuota pagada), es siempre, en los diseños de base de datos, una tabla independiente en la cual cada registro representa el pago de una única cuota. Nunca de varias, y menos aún de un año entero. Y si un mismo pago corresponde a una serie de conceptos de deuda cancelada, entonces la tabla pagos tiene otra tabla dependiente donde se detalla (registro a registro) cada uno de los conceptos contenidos en ese único pago.
A todos los efectos, esta tabla, tal como la tienes, no sirve ni te servirá para realizar ni este reporte ni ningún otro, sin tener que hacer enormes malabarismos con diferentes funciones de MySQL para intentar obtener la información que requieres.
A mi entender, la única solución que tienes es depurar ese modelo, y crear las tablas correctamente, y recién allí tendrás alguna oportunidad de hacer ese reporte.
Si no quieres o no puedes hacer cambios, y quieres usar las tablas tal y como las tienes, desde ya te advierto que las consultas serán muy complejas, y probablemente debas resolverlo parcialmente en programación de la aplicación.
Yo, personalmente, ni me molestaría en intentarlas. Es perder demasiado tiempo en algo que se puede hacer más fácil y optimizado de otro modo.
Queda a tu decisión.
Tips adicionales:
1) Los nombres y los apellidos van siempre en campos separados. Ponerlos juntos genera complicaciones en las búsqueda, y además no facilita los ordenamientos de listados.
2) Toda entidad que pueda aparecer relacionada a diferentes personas, como es el caso de una parroquia (más de un cliente puede pertenecer a la misma), no se pone como un campo de texto, sino como FK de una tabla fija donde se guarden los datos de esa entidad. Evita que el usuario escriba de dos formas diferentes el mismo dato, y reduce el espacio de disco usado en la tabla.
3) Un cliente que puede identificarse de una forma segura con su documento, no requiere de un ID numerico. Si el documento es un dato obligatorio, es preferible que sea también su PK.
4) Las serializaciones de datos en la aplicación no son necesariamente una buena idea para datos de una tabla. Como no representan datos para el SQL, pueden complicar las consultas más que beneficiarlas. Ten en cuenta que el SQL no interpretará los datos contenidos, sino que los tomará como simples cadenas de texto.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
| 
