Buscar un n.º dentro de un texto

[keiva]

Hola a todos.

Tengo estas dos tablas

tabla1
ID TEXT
1 "10"
2 "10,35"
3 ""
4 "10,35,60"


tabla2
ID TEXT
10 "hola"
35 "hoo!"
60 "adios"


Quisiera buscar la un número referente a la culumna de un ID dentro de otra columna que contiene texto, para encontrar aquellos términos que contenga una palabra

Código SQL:

SELECT *
FROM
  tabla 1 u, tabla2 t
 WHERE
      (u.text LIKE CONVERT(t.id USING latin1)) && (t.text LIKE '%ho%');
 

Alguna

[Libras]

te explicas un poco mejor? con peras y manzanas si es posible :P

[keiva]

Intentaré explicar mejor mi propósito.

Tabla 1 (compradores)
ID TEXT
1 "10"
2 "10,35"
3 ""
4 "10,35,60"


Tabla 2 (productos)
ID TEXT
10 "peras"
35 "naranjas"
60 "manzanas"


La cuestión sería conocer que compradores compran naranjas

Iniciado por Libras

te explicas un poco mejor? con peras y manzanas si es posible :P

[gnzsoloyo]

Tabla 1 (compradores)
ID TEXT
1 "10"
2 "10,35"
3 ""
4 "10,35,60"

Eso que tienes se denomina "campo multivaluado", y están expresamente prohibidos en las bases de datos relacionales. Son un error de diseño de los peores y es por eso que cualquier consulta que hagas sólo te traerá problemas.

Si tienes una relación entre Compradores y Producto, NO se resuelve con un campo así, sino con una tabla intermedia relacional, que posee un registro por cada par relacionado de Comprador-Producto.

Yo que tu rediseño todo. Perdería menos tiempo.

[keiva]

Ya, pero el reto está en resolverlo mediante una sentencia.

Por eso pregunto la posibilidad de convertir el valor numérico del identificador del producto en texto para así poder compararlo mediante un LIKE

[gnzsoloyo]

Eso no es un "reto", esnun defecto de diseño que en la Facultad haría que reprobaras la materia.

Mira, si la vas a usar con LIKE, desde ya NO SIRVE. LIKE está definido para cadenas de caracteres y no para magnitudes escalares. Un ID no es parecido a. Es igual, mayor, menor o dentro de un rango, pero no es "parecido a".
Sólo podrias usarlo en el WHERE utilizando funciones como FIND_IN_SET ().

[keiva]

Me acabas de dar una idea

Código SQL:

locate(t.id, u.text)  && (t.text LIKE 'naranjas')
 

[gnzsoloyo]

Es una mala idea, y además es evidente que necesitas estudiar mucho más de SQL...
Mira, LIKE es una de las peores cláusulas que existen, y no es un comodín multiuso. El algoritmo interno de LIKE está diseñado para realizar búsquedas basadas en patrones, y NO para validar igualdades. No es lo mismo.
Usar un LIKE sin comodines (%) es un error porque obliga al parser a realizar modificaciones innecesarias en la lógica del plan de consulta.
Por su lado, LOCATE() también es una función ineficiente, que apunta a buscar un patrón dentro de una cadena, y tampoco está definida para manejar escalares (números). Esto se empeora debido a que una comparación de LOCATE obligatoriamente verificará el conjunto completo de segmentos posibles de un campo de caracteres, basado en la longitud de la cadena que se busca. El resultado de eso puede tener una performance espantosa, sin contar con su inseguridad, porque si buscases un valor como por ejemplo "35", puede devolverte aquellos que contengan, por ejemplo, 35, 135, 351, 121212235987876, o cualquier cosa así.
¿Te parece conveniente?
Obviamente es una muy mala decisión.


NO.
Yo te dije claramente que lo que debes hacer, si no quieres corregir ese error enorme de diseño en tus tablas y procesos, que lo que debes hacer es usar la función FIND_IN_SET(), para lo cual solamente tienes que acudir al manual de referencia (ver FIND_IN_SET()), donde claramente se expresa, por ejemplo, que está optimizada para aritmética de bits, lo que es fundamental porque los números se administran internamente en los DBMS como binarios, no como cadenas de texto:

the FIND_IN_SET() function is optimized to use bit arithmetic

En resumen, si quieres seguir con ese esquema mal diseñado (no es el unico error que contiene), tendrás que usar funciones de cadena. Y estas las deberás estudiar en el manual. Pero si quieres realmente resolver tus problemas presentes o futuros, debes modificar ese esquema de bases de datos y diseñarlo bien.
Hacer esto ultimo te ahorrará muchos sufrimientos y tiempo, y te permitirá hacer consultas optimizadas, eficientes, que en el esquema actual será imposible.

Es tu decisión.

[keiva]

Tomo nota.

Gracias por las aportaciones.