11 respuestas en este tema

[poliburro]

Hola amigos,

 

Desde hace tiempo hay un diseño de base de datos que me tiene sumamente inquieto. Imaginemos que un almacen nos solicita crearle un sistema de inventarios y ventas. El almacen vende lo siguiente:

 

Vehículos Abarrotes Mascotas Ropa Línea Blanca

 

De ahí deduzco que puede crearse una tabla de categorías. Luego entonces cada categoría tiene productos con los siguientes atributos:

 

Autos Abarrotes Mascotas Ropa    Línea Blanca

Marca    Marca        Raza        Marca    Marca

Modelo  Empaque   Edad       Modelo  

Año       Peso          Color       Talla       Piezas        

Color        

 

 

En este punto se me hace coherente crear una tabla donde cada entidad almacene su información y de esa manera evitar nulos.

 

Luego viene la tabla que va a registrar las ventas, y allí me asalta la duda. ¿Es correcto que una sola tabla tenga los campos de todas las entidades que se venden? ¿o que se genere un maestro con la información base de la venta y un detalle de venta por cada entidad y con sus propios atributos?

 

En el primer caso, al crear una única tabla se dará pie a la existencia de muchos campos nulos aunque los tiempos de búsqueda se reduce.

 

En el segundo caso, se asegura que no exitan campos nulos al vaciar los atributos de cada entidad vendida en sus respectivas tablas detalle pero eso incrementa los tiempos de búsqueda y la complejidad de la consulta para obtenerlos.

 

¿Qué opinan compañeros?

 

¿Cómo lo solucionarían ustedes?

[Héctor Randolph]

Los sistemas de ventas online tienen un mecanismo para esto.

 

Este tipo de sistemas no saben de antemano qué tipo de productos se pondrán a la venta, así es que al crear el catálogo debes configurar las categorías y además se pueden añadir todos los atributos que uno quiera para cada producto.

 

Las tablas que se utilizan son genéricas y aceptan múltiples tipos de atributos. Así es que si vas  a vender teléfonos celulares, tienes ya definidos algunos campos generales como por ejemplo: fabricante, marca, precio, etc.  Pero además puedes añadirle atributos adicionales que tu mismo configuras como son: color, peso, dimensiones, capacidad de almacenamiento, si cuenta con bluetooth, sistema operativo, etc. Adicionalmente para cada producto y atributo puedes limitar los valores que son permitidos, por ejemplo, en el atributo color puedes aceptar solamente (blanco, negro, gris).

 

Incluso tienen algunos mecanismos para crear combinaciones y configurar las tablas de precios, por ejemplo, algunos modelos de laptops cambian de precio dependiendo del color seleccionado. Así es que al elegir en la tienda en línea el color rojo o verde, el precio será mayor que si eliges el color negro.

 

Sería útil que le des una mirada a sistema de e-commerce como prestashop. Hay muchos sistemas open source que te pueden dar una idea más clara acerca de como implementarlo.

 

Saludos

[poliburro]

Gracias por el dato amigo.

 

He visto que esos diseños general campos nulos ya que algunos productos no cubren odas las características. Eso a mi toda la vida me ha hecho ruido por aquello de las formas normales de diseño. Pero creo que en situaciones como esta se acepta.

 

¿Qué opinas sobre esto en un modelo de herencia? Oracle permite heredar atributos de una tabla padre.

[tmsanchez]

Si en determinado momento esos campos son solo informativos, una idea que se me ocurre es tener una tabla con la siguiente estructura:

 

id_categoria int

nombre_categoria char(70)

atributos varchar(300)

 

En el campo atributos podrías poner la definición de los atributos en formato XML (o tal vez JSON) para que cuando asignes la categoría a un producto pudieras asignarlos, algo así:

 

ID_CATEGORIA

NOMBRE_CATEGORIA

ATRIBUTOS

1

AUTO

<auto><marca></>marca><modelo></modelo><color>/color></auto>

2

ROPA

<ropa><marca></marca><modelo></modelo><talla></talla></ropa>

 

Y al momento de asignar los productos quedaría algo así:

 

PRODUCTOS

ID_PRODUCTO

ID_CATEGORIA

NOMBRE_PRODUCTO

ATRIBUTOS

1

1

BORA

<auto><marca>WW</>marca><modelo>2015</modelo><color>AZUL</color></auto>

2

2

JEANS

<ropa><marca>FUROR</marca><modelo>AH78</modelo><talla>CH</talla></ropa>

 

Solo una idea...

 

Saludos.

[Héctor Randolph]

No veo a qué te refieres cuando dices que se generan nulos.

 

Lo que vas a tener es una lista enorme de atributos posibles para todos tus productos:

 

• color
• peso en Kg
• talla
• capacidad de disco duro en GB
• resolución en pixeles
• pulgadas en pantalla
• Dirección hidráulica
• Frenos ABS
• Transmisión manual / automática
• etc.

El hecho de que tengas muchos atributos posibles no implica que cada producto deba tenerlos todos.

 

Cada producto tendrá solamente los que le pertenezcan y realmente va a utilizar.

 

Por ejemplo: una tableta podría utilizar solamente

• color
• peso en Kg
• capacidad de disco duro en GB
• resolución en pixeles
• pulgadas en pantalla

Y son los datos que vas a capturar; si no tienes el dato simplemente omites el atributo para este producto.

 

Tal vez para otra marca de tableta tengas además otros atributos

• color
• peso en Kg
• capacidad de disco duro en GB
• resolución en pixeles
• pulgadas en pantalla
• Wifi
• USB
• BlueTooth
• MultiTouch

Entonces este producto tendrá más atributos apesar de ser también una tableta.

 

Es decir que el primer producto tiene 5 registros en una tabla llamada product_feature porque son los cinco atributos que capturaste para él, el otro producto tendra 9 registros en la misma tabla.

 

Incluso existe un mecanismo para que un posible comprador compare entre dos o más productos, en el ejemplo anterior, al comparar las dos tabletas, generas una lista con los atributos que son comunes para ambos productos y los presentas en una tabla en la pantalla

 

Te dejo el diagrama de base de datos de prestashop. Busca dentro de la zona inferior la sección Product. En especial las relaciones con la tabla feature

 

http://doc.prestasho...497/pdm-1.5.png

 

Saludos

[poliburro]

Si en determinado momento esos campos son solo informativos, una idea que se me ocurre es tener una tabla con la siguiente estructura:

 

id_categoria int

nombre_categoria char(70)

atributos varchar(300)

 

En el campo atributos podrías poner la definición de los atributos en formato XML (o tal vez JSON) para que cuando asignes la categoría a un producto pudieras asignarlos, algo así:

 

ID_CATEGORIA

NOMBRE_CATEGORIA

ATRIBUTOS

1

AUTO

<auto><marca></>marca><modelo></modelo><color>/color></auto>

2

ROPA

<ropa><marca></marca><modelo></modelo><talla></talla></ropa>

 

Y al momento de asignar los productos quedaría algo así:

 

PRODUCTOS

ID_PRODUCTO

ID_CATEGORIA

NOMBRE_PRODUCTO

ATRIBUTOS

1

1

BORA

<auto><marca>WW</>marca><modelo>2015</modelo><color>AZUL</color></auto>

2

2

JEANS

<ropa><marca>FUROR</marca><modelo>AH78</modelo><talla>CH</talla></ropa>

 

Solo una idea...

 

Saludos.

 

Es mujy buena idea compañero, pero me parece que podría resultar un poco engorrosa cuando se deban generar reportes. Por ejemplo, si piden las estadísticas de las tallas de ropa que cada mes se venden por marca.

 

 

 

No veo a qué te refieres cuando dices que se generan nulos.

 

Lo que vas a tener es una lista enorme de atributos posibles para todos tus productos:

 

• color
• peso en Kg
• talla
• capacidad de disco duro en GB
• resolución en pixeles
• pulgadas en pantalla
• Dirección hidráulica
• Frenos ABS
• Transmisión manual / automática
• etc.

El hecho de que tengas muchos atributos posibles no implica que cada producto deba tenerlos todos.

 

Cada producto tendrá solamente los que le pertenezcan y realmente va a utilizar.

 

Por ejemplo: una tableta podría utilizar solamente

• color
• peso en Kg
• capacidad de disco duro en GB
• resolución en pixeles
• pulgadas en pantalla

Y son los datos que vas a capturar; si no tienes el dato simplemente omites el atributo para este producto.

 

Tal vez para otra marca de tableta tengas además otros atributos

• color
• peso en Kg
• capacidad de disco duro en GB
• resolución en pixeles
• pulgadas en pantalla
• Wifi
• USB
• BlueTooth
• MultiTouch

Entonces este producto tendrá más atributos apesar de ser también una tableta.

 

Es decir que el primer producto tiene 5 registros en una tabla llamada product_feature porque son los cinco atributos que capturaste para él, el otro producto tendra 9 registros en la misma tabla.

 

Incluso existe un mecanismo para que un posible comprador compare entre dos o más productos, en el ejemplo anterior, al comparar las dos tabletas, generas una lista con los atributos que son comunes para ambos productos y los presentas en una tabla en la pantalla

 

Te dejo el diagrama de base de datos de prestashop. Busca dentro de la zona inferior la sección Product. En especial las relaciones con la tabla feature

 

 

http://doc.prestasho...497/pdm-1.5.png

 

Saludos

 

 

Hola amigo, había entendido que todos los atributos estaban como columnas en una tabla. Por ello lo que decía de los nulos.

Entiendo mejor el concepto que comentas. En este caso entonces tenemos una tabla de Id_atributo, valor. Pero entonces, ¿de qué tipo declararías valor? por que si lo declaras  como alfanumérico deberás hacer procesos de conversión cuando leas los datos, (Fecha,  numérico, etc) lo que me lleva a pensar que para optumizar lecturas valdría la pena agregar tantas columnas como tipos de datos puedan tener los atributos pero eso, generaria nuevamente el problema de nulos.

[Héctor Randolph]

¿En qué casos tendrías qué hacer una conversión?

 

Los atributos como Color, Talla, Resolución, Bytes, etc. no creo que tengas la necesidad de operar con ellos, son simplemente de carácter informativo. Es decir, que los puedes mostrar en tus reportes como vienen (alfanuméricos).

 

Por ejemplo. Si te refieres a unidades de medida, cantidades, precios, fechas de venta, etc.

 

Esto es algo común a todos los productos que lleguen al almacén o a las tiendas y obviamente que tendrás los campos y las tablas para manejarlos.

 

Tal vez tu sepas de algún ejemplo de atributo que requiera ser convertido para operar con él.

 

Saludos

[poliburro]

Tal vez tu sepas de algún ejemplo de atributo que requiera ser convertido para operar con él.

 

Saludos

 

Atributos como fecha. Si por ejemplo un artículo es perecedero tiene una fecha y si lo almacenas como varchar, la consulta sobre ese atributo tendrá un coste adicional a hacer la conversión de date a varchar.

[poliburro]

Este me parece que es un tema sumamente interesante... Revisaré a detalle el diseño que has compartido amigo Héctor.

 

Saludos.

[Héctor Randolph]

De acuerdo, aunque en ese caso estamos hablando de un campo que es común a todos los productos que es la fecha de ingreso al almacén.

 

Sin embargo, se me ocurren casos más complejos como una consulta que filtre todos los teléfonos por tamaño de pantalla en un rango entre 2.2 y 4.7 pulgadas.

 

Entonces si tendríamos un problema. Este tipo de filtros si pueden ocasionar un problema con este tipo de diseño.

 

Pero aún así no lo descartaría tan rápido.

[Desart]

No se si te valdrá, pero yo en una ocasión en un programa hace tiempo use 3 campos para algo muy parecido, te lo digo de memoria, pero si quieres y esperas un par de días te lo pongo como estaba, el funcionamiento era el siguiente:

 

1º campo era el nombre del atributo (color, caducidad, tamaño, etc.)

2º campo era un char de 1 carácter con el tipo de atributo (Fecha=D, String=S, Integer=I, color=C, etc.)

3º campo era el valor del atributo

 

Luego usaba una función que me permitía hacer la converción cuando era necesario, sabiendo con el 2 campo el tipo y pasando el valor del mismo con el 3 campo

[poliburro]

No se si te valdrá, pero yo en una ocasión en un programa hace tiempo use 3 campos para algo muy parecido, te lo digo de memoria, pero si quieres y esperas un par de días te lo pongo como estaba

 

Muchas gracias amigo, esperaré tu aporte que seguramente será muy enriquecedor.