Como harian esta parte del diseño ?, a simple vista parece FACIL

altairon · #1 (**permalink**) 28/12/2009, 16:05

saludos , me gustaria saber como ustedes implementarian un diseño como el que tiene ebay, osea , no todo el schema de base de datos, sino solo una parte en particular, que es la siguente:

cuando se registra un producto en ebay, se le debe de seleccionar la categoria, pero esa categoria pudiera tener mas suc y sub, etc categorias , eso se soluciena con hacer esto:

Categoria
idCategoria
nommbre
idCategoriaPadre

no tengo problemas hasta ahi, lo que me resulta dificil hacer es esto:

cuando uno selecciona una categoria , porejemplo , zapatos , al producto a registrar se le activa nuevas opciones correspondientes a la categoria zapato:
ejem: talla , condicion , etc

si seleccionas una categoria de "procesadores" como ejemplo, te aparecen nuevas opciones como : tipo de procesador , fabricante , etc.

en esa logica, no se me ocurre como hacer esa estructura, si tieen alguna pista profavor una ayudadita se los agraedeceria , gracias

gnzsoloyo · #2 (**permalink**) 28/12/2009, 16:20

No te sorprendas, pero es posible hacerlo con una sola tabla. Ten en cuenta que los ID de las categorías son invisibles en la web (en todo caso se renumera la lista en forma dinámica, mientras los ID están "escondidos" en la memoria).
Lo único que necesitas es saber que la cabeza de la cadena es aquel registro cuyo idPadre es NULL, y la última linea de hojas es aquella que no puede devolver listas.
He visto ejemplos así en las bases de datos para ejercitación en el curso de DBA de Oracle.

altairon · #3 (**permalink**) 28/12/2009, 17:05

gracias por contestar, el tema de categorias lo tengo manejable, no tengo problemas en saber cual es el padre de todas las categorias o cual es el ultima hoja o hijo de la estructura, mi pregunta radica en que si selecciono una de estas categorias , en mi formulario de registro de producto me aparescan nuevas opciones , dependiendo a la categoria seleccionada , nose como implementar esa parte, por eso nesecito ayuda en esa parte , pero muchas GRACIAS gnzsoloyo POR TOMARTE UN MINUTO EN MI SOLICITUD :D

Osdiwe · #4 (**permalink**) 28/12/2009, 18:09

Yo haría dos tablas, una con las categorías y otra que serian las características de las categorías.

gnzsoloyo · #5 (**permalink**) 28/12/2009, 18:39

Cita:

mi pregunta radica en que si selecciono una de estas categorias , en mi formulario de registro de producto me aparescan nuevas opciones , dependiendo a la categoria seleccionada , nose como implementar esa parte, por eso nesecito ayuda en esa parte , pero muchas

Cada selección es o una consulta nueva a la base para que retorne los valores hijos de esa categoría, o bien una llamada a una función en PHP que, habiendo guardado en memoria la tabla completa de categorías, te devuelva los valores de la nueva lista.
Yo no veo cuál es el problema en implementarlo.
En cuanto a lo que dice Osdiwe, es sólo complicar el modelo de datos sin ninguna ventaja, ya que las características de una categoría sólo pueden ser atributos de la misma categoría. ¿Para qué crear una tabla nueva que sólo puede tener una relación 1:1 con la de Categorías?

Osdiwe · #6 (**permalink**) 28/12/2009, 18:50

Cita:

Iniciado por gnzsoloyo

Cada selección es o una consulta nueva a la base para que retorne los valores hijos de esa categoría, o bien una llamada a una función en PHP que, habiendo guardado en memoria la tabla completa de categorías, te devuelva los valores de la nueva lista.
Yo no veo cuál es el problema en implementarlo.
En cuanto a lo que dice Osdiwe, es sólo complicar el modelo de datos sin ninguna ventaja, ya que las características de una categoría sólo pueden ser atributos de la misma categoría. ¿Para qué crear una tabla nueva que sólo puede tener una relación 1:1 con la de Categorías?

Toda la razón gnzsoloyo. Aunque lo planteé así porque quizá una categoria tenga 4 características y otra 10. Entonces como crees que sería mejor hacerlo, ¿en 2 tablas (una para categorías y otra para las características con un idFK de la categoria) o hacer un campo en la tabla categorías y guardarlas tipo: caracteristica1;caracteristica2;etc... y luego recuperarlas con explode o algo así?

Me irá bien tu opinión porque pronto tendré que plantearme algo similar.

Gracias.

altairon · #7 (**permalink**) 28/12/2009, 18:55

gracias por sus respuestas, teniendo en cuenta que cada categoria puede tener diferentes atributos. Los attributos de la categoria automovil son muy diferentes al de una prenda de vestir . creo que por eso , todo esta estructura debe ser lo mas dinamica que pueda.

para gnzsoloyo, si te entiendo bien , me dices que los atributos especiacle deben estar en la tabla categoria? y dependiendo a la categoria a devolver , me muestre los atributos a usar ?

recurda que en algun momento voy a guardar datos como "marca de motor", ese dato no se va a guardar en la tabla categoria. nose si me dejo entender.

gnzsoloyo · #8 (**permalink**) 28/12/2009, 18:55

¿A qué le estás llamando "características de una categoría"?
Ejemplifica para que sea más claro.

altairon · #9 (**permalink**) 28/12/2009, 18:59

Osdiwe , esta estructura lo usa ebay, y me llama mucho la atencion y tambien es un requerimeinto para una palicacion en desarrollo , por eso estoy viendo la mejor anera de como hacerlo, hay que recordar que el numero de caracteristicas no se puede determinar , asi que si hacemos algo como caract1, cart2 .., caractn como campos en la tabla Categoria , no seria muy eficiente , please, gracioas por su tiempo, espero solucionar este problema, :D

altairon · #10 (**permalink**) 28/12/2009, 19:04

OK gnzsoloyo, por ejemplo, la tabla categoria tiene un registro que se llama , "sapatos de vestir" , sus caracteristicas serian "talla,color,marca,numero"

podemos tener otro registro en la tabla categoria , por ejemplo "Audiolibros" , para esta categoria sus caracteristicas serian "isbn, autor, fechaPublicacion"

en los dos ejemplos, si comparamos , nos daremos cuenta que por ejemplo , un audiolibro nunca tendria una caracteristica como "talla" , ya que talla solo debe estar disponible cuando se seleccione la categoria "sapatos de vestir" de la tabla categoria, espero haber sido un poco claro con esto, gracias por su tiempo

altairon · #11 (**permalink**) 28/12/2009, 19:05

OK gnzsoloyo, por ejemplo, la tabla categoria tiene un registro que se llama , "sapatos de vestir" , sus caracteristicas serian "talla,color,marca,numero"

podemos tener otro registro en la tabla categoria , por ejemplo "Audiolibros" , para esta categoria sus caracteristicas serian "isbn, autor, fechaPublicacion"

en los dos ejemplos, si comparamos , nos daremos cuenta que por ejemplo , un audiolibro nunca tendria una caracteristica como "talla" , ya que talla solo debe estar disponible cuando se seleccione la categoria "sapatos de vestir" de la tabla categoria, espero haber sido un poco claro con esto, gracias por su tiempo

paloto · #12 (**permalink**) 29/12/2009, 12:01

Vale, yo haría las siguientes tablas (he puesto registros de ejemplo para que se entienda):

Productos
ID / NOMBRE / CATEGORIA
1 / El Código Da Vinci / 1
2 / Los Pilares de la Tierra / 1
3 / Pentium 4 / 2
4 / Acer 9877 / 4
5 / Peugeot 307 / 3
6 / Audi A4 / 3

Categorías
ID / NOMBRE / CATEGORIA_PADRE
1 / Libro / NULL
2 / Ordenador / NULL
3 / Coche / NULL
4 / Portátil / 2

Caracteristicas
ID / NOMBRE / CATEGORIA_ID
1 / Numero de paginas / 1
2 / Autor / 1
3 / Tapas duras / 1
4 / Memoria RAM / 2
5 / Marca / 2
6 / Potencia motor / 3
7 / Consumo / 3
8 / Duración batería / 4

Caracteristica_Producto
ID / CARACTERISTICA_ID / PRODUCTO_ID / VALOR
1 / 1 (Numero de páginas) / 1 (El Código da Vinci) / 1400 (páginas)
2 / 2 (Autor) / 1 (El código...) / Dan Brown
3 / 1 ( Núm. Pag.) / 2 (Los Pilares...) / 1300 (pág.)
4 / 8 (Duracion bateria) / 4 (Acer...) / 10 (horas)
etc.

Así tendrías para cada categoría sus características (tendrías que obtener también las de sus categorías padre) y para cada producto podrías asignarle el valor para cada característica.

Espero haberme explicado correctamente, si no es así, avísame que lo extiendo un poco más :)

Un saludo

gnzsoloyo · #13 (**permalink**) 29/12/2009, 15:35

Yo sostengo que con esto es suficiente:

Código SQL:

Ver originalCategoria
ID  | NOMBRE                | CATEGORIA_PADRE
1   | Libro                 | NULL
2   | Ordenador             | NULL
3   | Coche                 | NULL
4   | Portatil              | 2
5   | Numero de paginas     | 1
6   | Autor                 | 1
7   | Tapas duras           | 1
8   | Memoria RAM           | 2
9   | Marca                 | 2
10  | Potencia motor        | 3
11  | Consumo               | 3
12  | Duracion bateria      | 4
13  | 1 hora                | 12
14  | 2 horas               | 12
15  | 4 horas               | 12
16  | 6 horas               | 12

Por otro lado, cuando llegas al nivel de datos de los productos, es conveniente separarlos, si en diferentes tablas según sus atributos, por cuanto los atributos que le dan identidad a un libro son demasiado diferentes de un vehúculo, una prenda de vestir, un zapato o una computadora.
En esos niveles si ya se debe hacer un trabajo más fino.
Un tip que puedo agregarte es que es relativamente innecesario indicar el tamaño de un libro o la cantidad de páginas si le pones el ISBN (codigo internacional de identificacion de publicaciones), ya que el mismo libro (digamos "Cándido o el optimismo", tienen diferentes ISBN según cada edición, tamaño de libro, cantidad de páginas, idioma, presentación, y un lago etcétera; datos que son provistos a nivel internacional.

altairon · #14 (**permalink**) 29/12/2009, 21:46

[B]Ante todo les doy mil gracias por su tiempo para resolver esta duda, bueno, aquí planteo mi punto de vista, entiendo muy bien estos dos esquemas que plantean, pero solo tengo que no me cuadra bien . Por ejemplo: el esquema que plantea paloto es perfecto y se adecua perfectamente a mi requerimiento, esta muy bien normalizado, pero al normalizar tanto no se pierde algo de performancia ? , me refiero a esta parte de su diseño:

Categorías
ID / NOMBRE / CATEGORIA_PADRE
1 / Libro / NULL
2 / Ordenador / NULL
3 / Coche / NULL
4 / Portátil / 2

Caracteristicas
ID / NOMBRE / CATEGORIA_ID
1 / Numero de paginas / 1
2 / Autor / 1
3 / Tapas duras / 1
4 / Memoria RAM / 2
5 / Marca / 2
6 / Potencia motor / 3
7 / Consumo / 3
8 / Duración batería / 4

lo entiendo perfectamente , pero lo que plantea gnzsoloyo me llama la atencion , yaque podriamos reemplazar esa parte con esto(en realidad no se si es mas optimo tenerlo en una tabla o en dos, aver si me pueden aclarar esa parte), pero agrenado una columna adicional FLAG, el cual me dira si es una categoria o una caracteristica o atributo:
FLAG => 1 -> CATEGORIA ; 2 -> CARACTERISTICA O ATRIBUTO

Código SQL:

Ver originalCategoria
ID  |FLAG | NOMBRE                | CATEGORIA_PADRE
1   | 1   |Libro                 | NULL
2   | 1   |Ordenador             | NULL
3   | 1   |Coche                 | NULL
4   | 1   |Portatil              | 2
5   | 0   |Numero de paginas     | 1
6   | 0   |Autor                 | 1
7   | 0   |Tapas duras           | 1
8   | 1   |Memoria RAM           | 2
9   | 0   |Marca                 | 2
10  | 0   |Potencia motor        | 3
11  | 0   |Consumo               | 3
12  | 0   |Duracion bateria      | 4
13  | 0   |1 hora                | 12
14  | 0   |2 horas               | 12
15  | 0   |4 horas               | 12
16  | 0   |6 horas               | 12

Se que ese FLAG ¡NO SERIA NECESARIO! si sensamos que las caracteristicas siempre la dan el ultimo hijo de una categoria. es decir, si ya no tiene hijos, entonces es una caracteristica. "almenos es lo que creo que penso gnzsoloyo", pero pero si vemos el caso de la categoria "DVD'S Y MOVIES(Entendiendo que esta categoria tene mas subcategorias)", por ejemplo; NOTAREMOS QUE ESTA YA TIENE caracteristicas como "Formato, Rating ,etc" , ese es un caso, lo que trato de decir es que no es necesario ir al ultimo nodo para determinar si es una caracteristica o no, ya que en algunos casos no cumple.
ahora, porque se requiere esto ? , bueno, seria util por cuastion de criterio de busqueda , ya que no seria necesario ir a la ultima sub sub categoria para realizar el filtro correspondiete en la busqueda.

es como lo hace ebay, aqui un ejemplo:

[URL="http://dvd.shop.ebay.com/?_from=R40&_trksid=p3907.m38.l1313&_nkw=&_sacat=11 232"]http://dvd.shop.ebay.com/?_from=R40&_trksid=p3907.m38.l1313&_nkw=&_sacat=11 232[/URL]

si nos fijamos como trabaja el buscador de ebay, nos daremos cueta que tiene ese comportamiento .

Finalmente, para vincular los valores de las características con los productos, usaríamos lo que planteo paloto en esta tabla.

Caracteristica_Producto
ID / CARACTERISTICA_ID / PRODUCTO_ID / VALOR
1 / 1 (Numero de páginas) / 1 (El Código da Vinci) / 1400 (páginas)
2 / 2 (Autor) / 1 (El código...) / Dan Brown
3 / 1 ( Núm. Pag.) / 2 (Los Pilares...) / 1300 (pág.)
4 / 8 (Duracion bateria) / 4 (Acer...) / 10 (horas)

donde CARACTERISTICA_ID es un id de la tabla CATEGORIA pero con el FLAG en 0,
diciendo con esto que nos referimos a una caracteristica y no a una categoria.

ese es mi punto de vista , nose si estoy hablando piedras, XD , pero como esta parte es bien delicada en la aplicacion que estoy desarrolando, me interesa mucho que sea lo mas hermosaq que pueda, XD.

altairon · #15 (**permalink**) 29/12/2009, 21:48

aqui el link del la consulta que realize en ebay, al parecer no se nota bien:

http://dvd.shop.ebay.com/?_from=R40&_trksid=p3907.m38.l1313&_nkw=&_sacat=11 232

paloto · #16 (**permalink**) 30/12/2009, 01:41

Personalmente prefiero separarlas por varios motivos. Primero, porque son cosas distintas las categorías de las características/atributos y segundo porque este esquema es mucho más modular de tal forma que si yo por ejemplo, quiero especificar el tipo de dato que requiere cada característica/atributo lo puedo hacer directamente en la tabla de características añadiendo un campo "TIPO_DATO" para construir mejor el formulario de inserción de productos.

Además, me pongo en la situación en la que una categoría de productos no tenga ninguna característica/atributo. Según el sistema que plantea gnzsoloyo sería imposible diferenciar un registro tipo característica/atributo de una categoría sin características/atributos ya que ninguna de las dos tendría hijos. La solución sería crearle un registro hijo nulo a esa categoría, pero salta a la vista que no es la solución idónea.

No sé en cuanto a rendimiento cual de las dos es mejor (en cualquier caso la diferencia sería imperceptible) pero personalmente, prefiero tener la base de datos mejor estructurada, ya que al final esto siempre te ayuda ante cualquier eventualidad o cambio que quieras hacer en la misma.

Un saludo

Osdiwe · #17 (**permalink**) 30/12/2009, 04:28

Cita:

Iniciado por paloto

Personalmente prefiero separarlas por varios motivos. Primero, porque son cosas distintas las categorías de las características/atributos y segundo porque este esquema es mucho más modular de tal forma que si yo por ejemplo, quiero especificar el tipo de dato que requiere cada característica/atributo lo puedo hacer directamente en la tabla de características añadiendo un campo "TIPO_DATO" para construir mejor el formulario de inserción de productos.

Además, me pongo en la situación en la que una categoría de productos no tenga ninguna característica/atributo. Según el sistema que plantea gnzsoloyo sería imposible diferenciar un registro tipo característica/atributo de una categoría sin características/atributos ya que ninguna de las dos tendría hijos. La solución sería crearle un registro hijo nulo a esa categoría, pero salta a la vista que no es la solución idónea.

No sé en cuanto a rendimiento cual de las dos es mejor (en cualquier caso la diferencia sería imperceptible) pero personalmente, prefiero tener la base de datos mejor estructurada, ya que al final esto siempre te ayuda ante cualquier eventualidad o cambio que quieras hacer en la misma.

Un saludo

Totalmente de acuerdo. Lo que es más eficiente en cuanto a rendimiento lo desconozco, pero por organización, escalabilidad y concepto prefiero tenerlo en dos tablas.

Y enhorabuena por los 100 mensajes

altairon · #18 (**permalink**) 30/12/2009, 07:56

Saludos a todos ,

lo que dice paloto tiene toda la razón , y mas me convenció la parte que dijo para especificarle el tipo de dato a la característica/atributo. Una vez escuche que una fase como esta "muchas personas hacen normalizar solo porque los profesores dijeron que lo hagan" , y muchas veces escucho decir que al normalizar mucho ("lo que es lo ideal") requiere mucho trabajo, la performancia baja , pero si no normalizas todo, tendras una mejor performancia ("hablando estrictamente en la velocidad") , es como decir esto, para la tabla persona , hay que agregarle otra tabla sexo , para saber si es hombre o mujer. pero creo que hay que saber cuando se aplica eso, es por eso que pensé que aplicar algo con esto, pero el costo es que pierdes esca labilidad , ahora no se lo que piense gnzsoloyo , pero de todos modos les agradesco mucho

:apla uso:

: aplauso:

paloto · #19 (**permalink**) 30/12/2009, 09:13

Eso es. Hay que saber establecer un límite entre lo normalizado y lo práctico. Cada uno pone el suyo donde cree conveniente

Gracias por las felicitaciones

Ni me había dado cuenta de que ya llevaba 100 jeje

Un saludo