none
Campo Fecha Vencimiento Productos RRS feed

  • Pregunta

  • Estimados.

    Tengo la siguiente duda.

    Estoy modelando y tengo una tabla Producto, el cual contendrá alrededor de 50 mil productos.

    Estoy pensando en agregar un campo llamado FechaVencimiento, pero me di cuenta que solo el 20% de mis productos tendrá una Fecha de Vencimiento, entonces agregué otra tabla que contiene el IdFechaVencimiento, IdProducto y la FechaVencimiento, esto es correcto no ? o también sería correcto dejarla en la tabla Productos aunque el 80% sean valores NULL ?

    Saludos Cordiales.


    DBA SQL Server Santiago/Chile

    lunes, 18 de junio de 2018 1:03

Respuestas

  • Eso me parece correcto.  Me suena a la 4ta forma normal.  Normalmente yo luego de eso creo una vista que une ambas tablas para cuestiones de simplicidad.  Los productos que no vencen tendrán la fecha de vencimiento nula.  En C#, normalmente este tipo de construcción me implica el uso de una clase base y una derivada.

    public enum ProductTypes
    {
        Unknown = 0, //Desconocido, normalmente implica un valor inválido.
        NonPerishable = 1, //No Perecedero
        Perishable = 2 //Perecedero
    }
    public class Product : Entity
    {
        public ProductTypes ProductType { get; set; }
        //Etc. Otras propiedades.
    }
    
    public class PerishableProduct : Product
    {
        public DateTime BestBefore { get; set; }
    }

    Luego entonces, su capa de datos encargada de crear objetos Product, creará ya sea objetos Product o PerishableProduct según tengan o no una fecha de vencimiento.  Los consumidores de objetos Product pueden usar la propiedad ProductType para saber si pueden hacer un cast a PerishableProduct o no.

    Ahora bien, eso sería mi aporte, creo yo, pero necesito hacerle notar algo:  No me parece que la fecha de vencimiento corresponda a la definición de un producto.  Por ejemplo, yo imagino que en su tabla de productos uno define cosas como "Atún Sardimar 320g, Lata", o "Coca Cola 354ml, Lata", y probablemente incluye cosas como el código de barras para el punto de venta.  Si estoy en lo cierto, no es correcto decir que el producto tiene fecha de vencimiento porque en cualquier momento en inventario tendremos latas de atún con distintas fechas de producción y por lo tanto distintas fechas de vencimiento.  Entonces tenemos un único registro de producto en base de datos, pero solamente un campo de fecha de vencimiento cuando en realidad tenemos muchas latas con distintas fechas de vencimiento dependiendo de su fecha de producción.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 19:22
    lunes, 18 de junio de 2018 2:15
  • Hola:

    Como matiza webJose, en la última parte de su post, yo creo que eso no es de producto. (Si lo implementas en producto, solo podrás disponer de una fecha). No es un atributo propio. Las caducidades son parte del proceso de compra, venta, fabricación o como se pongan en el escenario en cuestion.

    Por tanto para mi, es detalle de mi compra, subdetalle de fecha de caducidad de cada uno de los elementos de mi compra. O intentando ser más claro, si compro en una linea de compra 10 unidades de un producto, 5 van a un lote 5 van a otro lote, porque es mi lote el que puede contemplar las fechas de caducidad.

    IdCompra, IdLineaCompra, IdLote, Articulo, FechaCaducidad

    o algo del estilo.

    Un saludo

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 19:22
    lunes, 18 de junio de 2018 7:27
  • Considero que es la mejor forma de realizarlo, tambien podría sugerir que en la nueva tabla pueda agregar un campo Lote o algo por el estilo ya que pueden existir los mismos productos con diferente fecha de vencimiento y puede ayudarle a un mejor control en que lote y fecha de ingreso de ese lote se ingresó ese producto.

    Saludos

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 19:22
    lunes, 18 de junio de 2018 18:47
  • Es una forma práctica de verlo, pero es lo que yo dije.  Yo dije que es la forma de implementar la 4ta forma normal, y eso es independiente de la distribución de datos.

    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 21:10
    lunes, 18 de junio de 2018 19:58

Todas las respuestas

  • Eso me parece correcto.  Me suena a la 4ta forma normal.  Normalmente yo luego de eso creo una vista que une ambas tablas para cuestiones de simplicidad.  Los productos que no vencen tendrán la fecha de vencimiento nula.  En C#, normalmente este tipo de construcción me implica el uso de una clase base y una derivada.

    public enum ProductTypes
    {
        Unknown = 0, //Desconocido, normalmente implica un valor inválido.
        NonPerishable = 1, //No Perecedero
        Perishable = 2 //Perecedero
    }
    public class Product : Entity
    {
        public ProductTypes ProductType { get; set; }
        //Etc. Otras propiedades.
    }
    
    public class PerishableProduct : Product
    {
        public DateTime BestBefore { get; set; }
    }

    Luego entonces, su capa de datos encargada de crear objetos Product, creará ya sea objetos Product o PerishableProduct según tengan o no una fecha de vencimiento.  Los consumidores de objetos Product pueden usar la propiedad ProductType para saber si pueden hacer un cast a PerishableProduct o no.

    Ahora bien, eso sería mi aporte, creo yo, pero necesito hacerle notar algo:  No me parece que la fecha de vencimiento corresponda a la definición de un producto.  Por ejemplo, yo imagino que en su tabla de productos uno define cosas como "Atún Sardimar 320g, Lata", o "Coca Cola 354ml, Lata", y probablemente incluye cosas como el código de barras para el punto de venta.  Si estoy en lo cierto, no es correcto decir que el producto tiene fecha de vencimiento porque en cualquier momento en inventario tendremos latas de atún con distintas fechas de producción y por lo tanto distintas fechas de vencimiento.  Entonces tenemos un único registro de producto en base de datos, pero solamente un campo de fecha de vencimiento cuando en realidad tenemos muchas latas con distintas fechas de vencimiento dependiendo de su fecha de producción.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 19:22
    lunes, 18 de junio de 2018 2:15
  • Hola:

    Como matiza webJose, en la última parte de su post, yo creo que eso no es de producto. (Si lo implementas en producto, solo podrás disponer de una fecha). No es un atributo propio. Las caducidades son parte del proceso de compra, venta, fabricación o como se pongan en el escenario en cuestion.

    Por tanto para mi, es detalle de mi compra, subdetalle de fecha de caducidad de cada uno de los elementos de mi compra. O intentando ser más claro, si compro en una linea de compra 10 unidades de un producto, 5 van a un lote 5 van a otro lote, porque es mi lote el que puede contemplar las fechas de caducidad.

    IdCompra, IdLineaCompra, IdLote, Articulo, FechaCaducidad

    o algo del estilo.

    Un saludo

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 19:22
    lunes, 18 de junio de 2018 7:27
  • Considero que es la mejor forma de realizarlo, tambien podría sugerir que en la nueva tabla pueda agregar un campo Lote o algo por el estilo ya que pueden existir los mismos productos con diferente fecha de vencimiento y puede ayudarle a un mejor control en que lote y fecha de ingreso de ese lote se ingresó ese producto.

    Saludos

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 19:22
    lunes, 18 de junio de 2018 18:47
  • Hola.

    Gracias por responder, tienen toda la razón que los productos tienen fecha de vencimiento, el ejemplo que use fue erróneo, pero me servia para ejemplificar mi modelo de datos.

    Como conclusión la mejor manera de normalizar, seria que si una columna contiene un bajo % de datos NO NULL es mejor abrirla a otra tabla.

    Saludos y gracias como siempre.


    DBA SQL Server Santiago/Chile

    lunes, 18 de junio de 2018 19:22
  • Es una forma práctica de verlo, pero es lo que yo dije.  Yo dije que es la forma de implementar la 4ta forma normal, y eso es independiente de la distribución de datos.

    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    • Marcado como respuesta CMAPM lunes, 18 de junio de 2018 21:10
    lunes, 18 de junio de 2018 19:58
  • Gracias Jose.

    DBA SQL Server Santiago/Chile

    lunes, 18 de junio de 2018 21:10