GROUP BY a un campo "array"

[FuLaNo_]

Hola gente:

Mi problema es el siguiente, quiero hacer un "top ten" con los tags más usados que estan guardados en un campo con el siguiente formato: tag, tag, tag, tag (ej: php, mysql, apache, asp).

Mi consulta sql, para que entiendan, es la siguiente:

Código:

SELECT `tags`, COUNT(tags) total FROM `cyt_library` GROUP BY `tags` ORDER BY `total` DESC LIMIT 10

Por ejemplo:

En mi base tengo
registro 1: php, mysql
registro 2: php, apache
registro 3: asp
registro 4: asp, mysql

Y el resultado que quiero es
php (2)
asp (2)
mysql (2)
apache (1)

Como puedo lograr esto??

[Cluster]

Ya casi lo tenìas .. te faltò el "alias" si quieres para obtener comodamente el resultado de tu cuenta (COUNT()) ..

Código PHP:

  SELECT `tags`, COUNT(tags) AS total FROM `cyt_library` GROUP BY `tags` ORDER BY `total` DESC LIMIT 10 
   

Y en PHP como siempre aplicas un mysql_fetch_array() o lo que gustes ..

Un saludo,

[FuLaNo_]

Hola Clueste!

En mi caso sin "AS" funciona igual... pero mi problema sigue estando, al parecer no me explique bien...

Si en mi base tengo
registro 1: php, mysql
registro 2: php, apache
registro 3: asp
registro 4: asp, mysql

Con la consulta actual obtengo:
php, mysql (1)
php, apache (1)
asp (1)
asp, mysql (1)

Cuando lo que busco es
php (2)
mysql (2)
asp (2)
apache (1)

Me entendes??, lo que yo quiero es que cuente cada tag (,) por separado... digamos, es como que deberia hacer un "split" por coma (,) del campo "tags" y ahí hacer el COUNT... pero no se como hacerlo directamente en la consulta...

El COUNT actual me estra agrupando el campo entero y no el tag separado por coma...

PD: la coma (,) puedo cambiarla por un espacio, o cualquier caracter que se requiera para facilitar la consulta mysql...

[Cluster]

Pero .. en tu campo "tag" que tienes? literalmente.

Si tienes tus palabras clave separadas por "comas" .. así realmente no tengo idea como hacerlo en SQL .. Lo que deberiás haber hecho justamente para facilitar este tipo de consultas estadísticas es:

tabla cyt_library
id_cyt_library
etc campos
etc campos ...

tabla tags_cyt_library
id_tags_cyt_library
id_cyt_library
tag_nombre

Así puedes compone una sentencia SQL para obtener el resultado que esperas.

Es muy comodo meter registros "serializados" (separados por comas) .. pero eso sirve sòlo para ingresar esos datos comodamente y "verlos" .. pero a la hora de hacer este tipo de consultas estadísticas se complica enormemente y baja muchooooo el rendimiento de lo que puedas implementar.

Un saludo,

[Cluster]

El COUNT actual me estra agrupando el campo entero y no el tag separado por coma...

El "COUNT" afecta a registros no a valores que puedas tener en campos.

Una sentencia SQL sòlo no te sirve .. vas a tener (si quieres seguir por esta vìa) que consultar tus datos en general ... y luego ir aplicando "explode()" a cada campo .. separar los datos en array's para seguir operando con el array (con funciones de array's para hacer totales y demás).

Un saludo,

[FuLaNo_]

El tema es que no queria ocupar otra tabla porque es algo simple, literalmente lo que hago es esto:

Un usuario escribe un articulo y alli tiene que completar un campo llamado "categorias" en donde tiene que separar con copa las categorias relacionadas a ese articulo, por ejemplo

titulo: paginar resultados de una consulta MySQL con PHP
text: .....
categorias: php, mysql

me explico?

Pero bueno, al parecer no hay manera de hacerlo y tendré crear otra tabla para relacionarla con el articulo...

Siempre trabajo con tablas relacionadas, no se porque esta vez se me cruzo hacerlo de esta otra manera :p

[califa010]

Buenas, coincido, lo mejor que podés hacer es modificar la estructura de la base, ahora que estás a tiempo. Lo que "perdés" haciendo un join lo recuperás con creces en flexibilidad. (...y salud mental; una vez tuve que hacer algo parecido sobre una base que ya estaba armada y en producción, que la usaban unos cuantos scripts y no se podía modificar; hubo que hacer muchas "chanchadas" y de verlo nomás daba la impresión de que iba a fallar en cualquier momento...).

Incluso, te convendría usar 3 tablas. Porque si querés que "php", por ejemplo, sea una categoría, no debería ser un dato "tipeado" por el usuario, sino una opción (seleccionada de un combo, por ejemplo). De la otra manera, si alguien escribe "my sql" y viene otro y mete "mysql", no podrías agruparlas como una sola categoría.

En ese esquema, tendrías:

1) Artículos (id_articulo,título, texto, id_autor, etc, etc)
2) Categorías (id_categoria,descripcion -->1 - php, 2 - mysql, 3 - asp, etc, etc)
3) Artículos_categorías --> acá hacés la relación entre las dos tablas anteriores, simplemente vas a tener id_articulo e id_categoria (podrías agregarle una clave primaria, también; nunca sabés cuándo la vas a necesitar...)

Suerte
Califa

[Cluster]

Iniciado por FuLaNo_

El tema es que no queria ocupar otra tabla porque es algo simple, literalmente lo que hago es esto:

Un usuario escribe un articulo y alli tiene que completar un campo llamado "categorias" en donde tiene que separar con copa las categorias relacionadas a ese articulo, por ejemplo

titulo: paginar resultados de una consulta MySQL con PHP
text: .....
categorias: php, mysql

me explico?

Pero bueno, al parecer no hay manera de hacerlo y tendré crear otra tabla para relacionarla con el articulo...

Siempre trabajo con tablas relacionadas, no se porque esta vez se me cruzo hacerlo de esta otra manera :p

Ya te decía que la forma que usastes de almacenar datos sirve con poco esfuerzo para registrar una série de datos que no se usen nada más que para verlos (con menor o mayor medida de intervención para presentarlos según algún formato).

Pero, .. este "modelo de datos" .. ya se hace inviable para lo que ahora pretendes hacer. Siempre que diseñes tu "modelo de datos" debes sentarte un rato a pensar "que vas hacer con los datos" .. y así veras si usas un método de "normalización" u otro .. habrá casos que no valga la pena liarse con tablas anexas y otros que sí.

Un saludo,

[Cluster]

Iniciado por califa010

Buenas, coincido, lo mejor que podés hacer es modificar la estructura de la base, ahora que estás a tiempo. Lo que "perdés" haciendo un join lo recuperás con creces en flexibilidad. (...y salud mental; una vez tuve que hacer algo parecido sobre una base que ya estaba armada y en producción, que la usaban unos cuantos scripts y no se podía modificar; hubo que hacer muchas "chanchadas" y de verlo nomás daba la impresión de que iba a fallar en cualquier momento...).

Incluso, te convendría usar 3 tablas. Porque si querés que "php", por ejemplo, sea una categoría, no debería ser un dato "tipeado" por el usuario, sino una opción (seleccionada de un combo, por ejemplo). De la otra manera, si alguien escribe "my sql" y viene otro y mete "mysql", no podrías agruparlas como una sola categoría.

En ese esquema, tendrías:

1) Artículos (id_articulo,título, texto, id_autor, etc, etc)
2) Categorías (id_categoria,descripcion -->1 - php, 2 - mysql, 3 - asp, etc, etc)
3) Artículos_categorías --> acá hacés la relación entre las dos tablas anteriores, simplemente vas a tener id_articulo e id_categoria (podrías agregarle una clave primaria, también; nunca sabés cuándo la vas a necesitar...)

Suerte
Califa

Coincido plenamente .. sobre todo el la extra-normalización de las "categorìas" (o "tag" que llamas) ..

Un saludo,

[FuLaNo_]

ya estan hechas las tres ;), luego de crear la tabla de categorias me puse a pensar y tambien hice la de categorias predefinidas para armar los combos, o un list así puede seleccionar varios...

gracias a ambos por la ayuda ;)

Saludos!

[califa010]

De nada

Suerte
Califa