Detectar datos de base separados por comas

[javy7v]

Buenas gente os cuento el problema a ver si me podéis echar una mano.

Estoy haciendo una web sencillita para que luego la manejen unas personas que controlan muy poco de bases de datos , HTML etc...

El tema es que quiero que al insertar productos en la base , crear un campo en el que se indique separado por comas en que webs quieren que pueda aparecer ese producto ya que tienen varias webs relacionadas.

Algo asi:



Y luego en los distintos sitios donde me interese hacer un select llamando al que yo necesite , algo asi tenia pensado :

Código SQL:

SELECT * FROM producto WHERE externo_web='web1'
 

El problema es que parece que solo me detecta algo si pongo en el select el mismo texto exacto que hay en la base , vamos que la separación por comas no funciona , no me los valora como distintos elementos.

Alguna solución ¿ ? Nose si me habre explicado bien tampoco

[gnzsoloyo]

En primer lugar, estas modelando mal esa relación. Lo que corresponde es agregar dos tablas, una para las web y otra que relacione las web con los productos.
Eso seria lo correcto desde el lado de Bases de Datos.

Lo esencial es que se comprenda que un mismo producto puede relacionarse con N webs, y a su vez cada web puede relacionarse con N producto. Ese tipo de relaciones de cardinalidad N:M, en las bases de datos relacionalesobligatoriamente deben definirse con tablas que vinculen ambas entidades. Eso implica que hay tres tablas en juego: Producto, Web y producto_web, que las vincula.

¿Puedes hacerlo sin eso. Bueno, poder, peudes, pero estarías creando campos multivaluados (cosa prohibida en BBDD), que terminan trayendo muchísimos problemas a la hora de optimizar consultas, y en caso de usarlos deberás utilizar funciones de cadena para evaluar el WHERE. Y no de las buenas.
Adicionalmente, ese tipo de casos no es indexable de forma eficiente, por lo que crear índices no funcionará si no pones las webs con sus comas en el mismo orden que aparecen... o sea el mismo inconveniente.
Esa forma de guardar datos separdos por comas no te servirá tampoco usando índices FULLTEXT, porque al ser webs, loos nombres contienen puntos y los puntos son separadores de listas en el contenido de los indices FULLTEXT, por lo que tampoco serán eficientes para tu problema.

[Libras]

que DBMS usas???

[javy7v]

Iniciado por gnzsoloyo

En primer lugar, estas modelando mal esa relación. Lo que corresponde es agregar dos tablas, una para las web y otra que relacione las web con los productos.
Eso seria lo correcto desde el lado de Bases de Datos.

Lo esencial es que se comprenda que un mismo producto puede relacionarse con N webs, y a su vez cada web puede relacionarse con N producto. Ese tipo de relaciones de cardinalidad N:M, en las bases de datos relacionalesobligatoriamente deben definirse con tablas que vinculen ambas entidades. Eso implica que hay tres tablas en juego: Producto, Web y producto_web, que las vincula.

¿Puedes hacerlo sin eso. Bueno, poder, peudes, pero estarías creando campos multivaluados (cosa prohibida en BBDD), que terminan trayendo muchísimos problemas a la hora de optimizar consultas, y en caso de usarlos deberás utilizar funciones de cadena para evaluar el WHERE. Y no de las buenas.
Adicionalmente, ese tipo de casos no es indexable de forma eficiente, por lo que crear índices no funcionará si no pones las webs con sus comas en el mismo orden que aparecen... o sea el mismo inconveniente.
Esa forma de guardar datos separdos por comas no te servirá tampoco usando índices FULLTEXT, porque al ser webs, loos nombres contienen puntos y los puntos son separadores de listas en el contenido de los indices FULLTEXT, por lo que tampoco serán eficientes para tu problema.

Muchas gracias intentare plantearlo como me has dicho , no es que me guste mucho el tema de Bases y en un principio pense que no me sería necesario crear mas tablas.

Iniciado por Libras

que DBMS usas???

Si no me estoy confundiendo con lo que me preguntas MySql XD

[gnzsoloyo]

Muchas gracias intentare plantearlo como me has dicho , no es que me guste mucho el tema de Bases y en un principio pense que no me sería necesario crear mas tablas.

Te comento que, por experiencias que he visto de muchísimos foristas, cualquier intento de "simplificar" la cantidad de tablas lleva siempre a consultas de optimización imposible, complicadas, mucho trabajo adicional de programación y difícil mantenimiento de consistencia.
Los que nos dedicamos de lleno a las BBDD entendemos la postura de los programadores, pero debes entender que una base de datos bien desarrollada, facilita luego no tener que andar haciendo magia para lograr cosas que la aplicación necesita. Es un área muy técnica, y no quieres profundizar, sugiero que trates de conseguir un colaborador que pueda resolverte esa parte.
Te ahorrarás dolores de cabeza constantes.