[SOLUCIONADO] ¿Como se podría hacer la consulta?

[Benderzuelo]

Hola amig@s,

resulta que estoy atascado en una consulta, me explico...

La web es de anuncios, al dar de alta anuncios, se pueden guardar muchas opciones, como por ejemplo servicios, los servicios salen de una tabla llamada servicios la cual contiene solo la id y el nombre del servicio, hay muchos, y como hay muchos servicios a la hora de guardar, para no hacer un campo por cada servicio lo que hice es guardar los servicios en la tabla de anuncios por sus ids separados por comas, quedando así:

Servicios (1,4,7,8,9,12,15,26) etc...

Hasta ahí no hay problema, el problema viene ahora cuando estoy haciendo el filtro de búsqueda en la web y pueden seleccionar para buscar varios servicios, yo los recojo de la misma manera, pero... como comparo ahora por ejemplo si me seleccionan (1,4,6) con lo que hay en la tabla que podría ser mas o menos?

No tengo excesivos conocimiento de Mysql y estoy perdido.

Alguien me puede ayudar.

Muchas gracias por adelantado.

[gnzsoloyo]

En primer lugar, tu solución es incorrecta. Al tener una relación de cardinalidad N:M entre Anuncios y Servicios, la solución no es crear un campo por servicio, sino crear una tabla relacional entre Anuncios y Servicios.
Esa tabla contendría sólo dos atributos, que al mismo tiempo serían PK de la misma: anuncio_id, servicio_id).

Si ya la tienes mal hecha, lamento decirte que te obligará a crear consultas ineficientes, complejas y de poca precisión (esta última solo se soluciona con funciones nativas de MySQL).
Así que, ¿que quieres hacer? ¿crear la tabla como debes hacerlo, o parchar el funcionamiento de tu sistema y hgacer consultas de muy mala performance?

[Benderzuelo]

:( madre mia, es que ahora mismo rehacer la tabla me supone muchísimas horas, si es posible hacer una consulta que funcione aunque no sea eficiente te lo agradecería...

Al margen de esto y para futuras ocasiones, me gustaría saber, si tengo por ejemplo 50 opciones de opciones, tendría que hacer 50 tablas relacionales?, siempre?

Muchas gracias gnzsoloyo

[gnzsoloyo]

Si tienes todos los valores en un campo, la única solución es usar FIND_IN_SET en el WHERE (no, antes que preguntes, LIKE no te va a funcionar bien), pero para que devuelva resultados correctos deberás incluir un FIND_IN_SET:

Código MySQL:

SELECT a, b, c, d, e
FROM tabla
WHERE FIND_IN_SET(campo, '1')>0
  AND FIND_IN_SET(campo, '23')>0
  AND FIND_IN_SET(campo, '8')>0
 

Al margen de esto y para futuras ocasiones, me gustaría saber, si tengo por ejemplo 50 opciones de opciones, tendría que hacer 50 tablas relacionales?, siempre?

Eso no se puede responder sin conocer detalles del sistema. Tu ves 50 opciones, y yo puedo llegar a ver una tabla con 50 registros, o bien cuatro tablas con X registros cada una...

En resumen: describe el sistema completo, y qué representan cada una de esas 50 opciones, y veremos.
Un dato no es necesariamente una tabla. Un mismo objeto puede no ser una única tabla, y 150 formularios pueden en realidad ser 8 tablas. No depende de lo que veas en la pantalla o lo diferentes que parezcan los datos, sino en lo que esos datos representan y lo que hace el sistema.
Las bases de datos y la arquitectura de datos no son un terreno fácil para los programadores que se inician. Requiere cierto nivel de conocimiento y experiencia dominarlo.

Por otro lado, no te asustes con 50 miserables tablas. Trabajo con una base que tiene 683 tablas, y accedo a otros que tienen más de 1.000, y ni se notan.

[Benderzuelo]

Hola de nuevo gnzsoloyo, eres un crack, siempre me solucionas tu los problemas de consultas.

Te comento como tengo hechas mis tablas a ver si puedo aprender algo para próximos proyectos.

Tabla ANUNCIOS

idAnuncio, idUsuario, tipoAnunciante, idSeccion, nombre, telefono1, telefono2, idCiudad, web, idNacionalidad, alto, ancho, profundo, idiomas, texto, precio, dias(este es así como te he dicho separado por comas), horas(lo mismo), servicios(lo mismo), disponibilidad(lo mismo), fechaPublicacion, fechaModificacion, activo.

Los 4 campos que te he especificado entre paréntesis son los que tengo como te he comentado, o sea con varios valores separados por comas, y los valores son los ids de las tablas respectivas al nombre de dicho campo, no se si me he explicado, entonces ahí que debería haber hecho?, 4 tablas relacionales con el id del anuncio y el id de cada servicio?

Y luego en las consultas hacer INNER JOIN o algo así?

Gracias de nuevo, voy a probar lo de find_it_set

[gnzsoloyo]

No exactamente cuatro tablas...
Por lo pronto, partamos de la base que yo nosé qué representa "dias", "horas", ni "disponibilidad" en tu sistema. Si no lo explicas ni lo describes, podría interpretar cosas diferentes.
Los días pueden ser una lista de días de publicación, o un rango de inicio y fin, o bien periodos en meses, o tal vez días de la semana. No lo sé. Lo que posteas no lo aclara, porque no me estas dando las reglas del negocio que son las necesarias para un relevamiento.
Con las horas pasa lo mismo: No sé qué expresan, sin un rango de tiempo diario, semana, o vinculado con los días
Disponibilidad es el peor: No tengo ni la más mínima idea de a qué te refieres. Podría ser cualquier cosa.

Lo que yo puedo inferir, sí, de esta breve tabla es que lo que puede no estar bien planteado es el sistema en sí. Te has concentrado en la idea que que publicas avisos, y definibles los avisos como el todo del sistema cuando no lo es.
También estás mezclando los avisos con el cliente que los publica, lo que es un error. La tabla está desnormalizada.
Un aviso es lo que publicas, pero no es el método comercial de publicación, venta y cobranzas. Lo que existe es un aviso que representa lo que se publica, pero el uso de l servicio se plantea usualmente como un servicio que aplica durante X días, den base a un esquema de publicación, con cierta vigencia, servicios posibles y otros conceptos. En ese contexto lo que deberías haber creado es el esquema de lista de publicidad o lista de precios, y asociar cada a viso a esa lista.
Adicionalmente lo que haces es crear un set de tablas para administrar la aparición de las publicidades en forma pactada.

ASí como parece, el esquema que tienes parece simple en exceso, y tendrás muchos cuellos de botella en el sistema...

[Benderzuelo]

Vale vale, me extiendo más disculpa.

Los días son de lunes a domingo, y se guardaría de 1 a 7 tantos como marque
Las horas es la disponibilidad del servicio, y se guardaría también por ejemplo las horas, 15,16,17,18
Los servicios podrían ser carpintería, albañilería, pintura, etc, y se guardan igual las ids separadas por coma
y por ultimo la disponibilidad es geográfica, por ejemplo valencia, castellón, alicante y serían las ids de cada comunidad.

Con estos datos, tendría que haber hecho 4 tablas relacionales?

Gracias de nuevo

[gnzsoloyo]

Bueno, en realidad me parece que tu sistema necesita muchas tablas más que sólo cuatro...
Si bien ya se empieza a vislumbrar un poco más de lo que estás haciendo, aún hay muchas pregutnas sin respuesta que definirán la arquitectura de datos que realmente necesitarás.
Por empezar:
- ¿Estás diseñando un sistema de avisos clasificados, o de ofertas de servicios? No es lo mismo, y lo que se ve hasta ahora no me permite saberlo.ñ El modelo de datos de uno u otro es diferente.
- Si es uno de avisos: ¿Los avisos se pactan por día, y deben mostrarse entre determinadas horas? En ese caso, no necesitas listar las horas, sino el rango de inicio y fin. Ypara eso se necesitan dos campos, no uno, y ambos deben ser de tipo TIME, así como los de fecha que deben ser dos (inicio y fin, de nuevo), ambos de tipo DATE.
- Si los avisos deben aparecer en un rango de días, pero en rangos de horas espaciadas, se necesita una tabla para adminsitrar los días y cada rango de horas, por lo que esos cuatro atributos serían parte de OTRA tabla.
- Si los avisos son de servicios, y son los servicios los que se pueden prestar en determinadas horas y días, deberás aclarar una cosa: ¿Los horarios y días son los mismos para cualquier localidad? ¿Hay diferenciaciones por localidad?
- ¿Los diferentes tipos de servicios son en todas las localidades? ¿Tienen el mismo precio? ¿Los mismos horarios?

Así como están planeados, sigue faltando más información... Hay una gran diferencia de tablas y relaciones según sea una cosa (avisos clasificados) u otra (oferta de servicios)..

¿Se va entendiendo?

[Benderzuelo]

Hola gnzsoloyo,

Se trata de anuncios, o sea, yo por ejemplo soy electricista, pintor y carpintero, y pongo un anuncio en el que ofrezco mis servicios en el horario indicado, en las ciudades indicadas. No tiene más, está hecho tal cual me lo han pedido, lo quieren así, no puedo cambiar la forma en la que lo quieren.

Lo único que me gustaría saber es si para esas 4 relaciones debería haber hecho 4 tablas, pero con respecto a lo que tengo y no a lo que debería tener ya que no lo puedo cambiar ahora.

Gracias de nuevo.

[gnzsoloyo]

Bueno, te lo resumo:
1) Los campos multivaluados están prohibidos en el Modelo Entidad-Relación, y por consecuencia en las bases de Datos Relacionales, como MySQL, DB2; Oracle, SQL Server, PostgreSQL, etc.
2) Toda relación N:M entre dos entidades genera obligatoriamente una tabla relacional, cuya PK está formada por las PK de las tablas relacionadas. En ciertos casos se puede requerir un atributo adicional como discriminante.
3) Todo atributo propio de la relación (por ejemplo, inicio y fin, validez, activación, etc.) debe estar en la tabla relacional y no en las tablas base.
4) Toda relación 1:N requiere que la PK de la tabla de cardinalidad 1 sea FK en la tabla de cardinalidad N. Nunca al revés, y JAMÁS cruzadas.
5) Muchas otras cosas...