codigo de producto como primary key

[anubis]

Buenas de nuevo,

Se que es una pregunta muy basica, pero estaba intentando hacer una base de datos de productos de un super y tengo la duda de si el codigo del producto (el del codigo de barras) se pueda usar o no como clave primaria.
Estuve buscando en san google y, en principio, no recomiendan ese metodo sobretodo si va a usar en otras consultas, mejor usar un autoincremental.

La pregunta es si esto es correcto, como se puede usar la clave codigo de producto (numero del codigo de barras) para que las consultas sean agiles como con la primary key, (imagino que como index pero no seria tan rapido) porque firebird no tiene alternative key.

gracias

[lbuelvas]

Hola foristas, un cordial saludo.

Pues les voy a contar una experiencia reciente respecto a un sistema para cobro de catastro en Colombia (Impuesto Predial) donde el identificador de la tabla principal del sistema era el la cédula catastral de los inmuebles, todo estaba perfecto pero el gobierno cambio la estructura y contenido de esa cédula catastral. La decisión que tomé fue conservar como identificador la cédula catastral y hacer una conversión de datos, levantar llaves foráneas y actualizar todas las tablas donde se hacia referencia a la cédula catastral, y crear un campo para guardar la cédula catastral anterior.

Pero el problema se va a presentar en el futuro porque dentro de la cédula catastral hay 4 digitos que por el momento está en ceros (0000) pero que van a contener el codigo de Barrio / Vereda. Que sucede, esa concepción rompe el diseño de bases de datos pues eso 4 digitos no deberián forma parte de la llave primaria, la llave primaria depende de otras cosas para existir y puede variar en el tiempo y eso debe evitarse a toda costa.

Que me toca hacer ? Pues crear un identificador consecutivo oculto al usuario, crear una llave única (uk = unique key) para la cedula catastral porque eso si es seguro que no puede haber dos cedulas catastrales con igual valor.

Las consultas se pueden volver más complejas y más lentas y el trabajo de optimización se torna más importante.

Mi recomendación utiliza un consecutivo como identificador, utiliza el codigo del producto como llave alterna única UK (esto lo permite firbird) si y solamente si se garantiza que no habrá dos registros con igual código de producto.

Si el cliente por ejemplo quiere diferenciar por colores y tallas y los quiere manejar como productos diferentes los códigos también son distintos ?

[Casimiro Notevi]

... Puedes crear un índice para ese campo, si no lo usas como clave primaria. Por la velocidad no te preocupes, es igual, o más rápido.

[newtron]

Hola.

Un apunte sobre el tema de los códigos de barra. Aunque parezca extraño los códigos de pueden barra cambiar para un mismo artículo con lo que será fácil que te encuentres en existencias dos artículos idénticos pero con distintos códigos de barras lo que te generará un problema grave.

La solución para esto sería tener una tabla adicional de códigos en la que se guarde el código interno del artículo junto con su código de barras asociado y a la hora de buscar el artículo hacer una búsqueda del código de barras en esa tabla y luego buscar en la tabla de artículos el código interno que te devuelve esa búsqueda.

Esto es bastante útil puesto que puedes tener códigos de barras ilimitados para un mismo artículo y al mismo tiempo puedes asignarle a ciertos artículos de venta muy habitual códigos rápidos como el 1, 2, etc.

Saludos

[ElKurgan]

Sólo como apostilla, según algunas lecturas (Scott W. Ambler (http://www.ibase.ru/devinfo/mappingObjects.pdf), por ejemplo), no es buena idea usar como clave primaria cualquier dato que tenga que ver con las reglas de negocio. Pero sobre gustos...

Saludos

[Neftali [Germán.Estévez]]

Algún apunte más, aunque creo que ya te lo han comentado.

Los numéricos siempre son mejores como claves que los alfanuméricos.
Siempre puedes crearle un índice único por ese código, sin que sea clave primaria.
Asegúrate de que cumple condiciones de Pk o índice único.

No todos los códigos de barras lo cumplen. diferentes productos pueden tener el mismo cód. de barras (al menos en algunos campos) y el mismo artículo puede tener más de un código de barras.

[AzidRain]

Se debe utilizar un código que tu mismo generes basado en las necesidades del cliente. Este código es lo que se conoce como SKU (Stock Keeping Unit) y debe ser único para cada artículo y por supuesto puede tener ligados n número de códigos de barras siempre que sea exactamente el mismo artículo ya que los fabricantes a veces cambian sus códigos cuando cambian la presentación, el empaque o la fórmula de sus productos. Para el caso de los supermercados por lo regular los SKUs se dividen en departamentos y el código puede contener el número del mismo.

Por ejemplo tenemos los siguientes departamentos con sus códigos:

Abarrotes 92
Químicos del Hogar 13
Salud y Belleza 02..

Entonces los SKus de abarrates podrían empezar con 92 seguido del número de cifras que requieras según tu estimación de stock (92000 al 92999 por ejemplo).

Asi en todo momento puedes identificar a que departamento pertenece un artículo solo sabiendo su SKU, además te puede servir para poder dar de alta y vender artículos que de origen no traen código de barras, dicho código lo puedes generar tu mismo.

[anubis]

Gracias a todos por responder,

Si, ya lo aplique como decis

CREATE TABLE PRODUCTOS
(
ID_PRODUCTO Integer NOT NULL,
CODIGOPRODUCTO Varchar(20) CHARACTER SET UNICODE_FSS,
NOMBREPRODUCTO Varchar(50) CHARACTER SET UNICODE_FSS,
ID_FAMILIA Integer,
ID_SUBFAMILIA Integer,
PRIMARY KEY (ID_PRODUCTO)
);

ALTER TABLE PRODUCTOS ADD
FOREIGN KEY (ID_FAMILIA) REFERENCES FAMILIAS (ID_FAMILIA);
ALTER TABLE PRODUCTOS ADD
FOREIGN KEY (ID_SUBFAMILIA) REFERENCES SUBFAMILIA (ID_SUBFAMILIA);
CREATE UNIQUE INDEX IDX_PRODUCTOS1 ON PRODUCTOS (CODIGOPRODUCTO);

Bueno eso lo he sacado del flamerobin de lo que ya hice.

La tabla de ventas y detalleventas quedaria asi, no se si esta bien.

CREATE TABLE ventas
(
id_venta integer not null,
fecha date,
primary key (id_venta)
);

CREATE TABLE detalleventa
(
id_ventadetalle integer not null,
id_venta integer,
id_producto integer,
cantidad smallint,
primary key (id_ventadetalle),
foreign key (id_venta) references ventas (id_venta),
foreign key (id_producto) references PRODUCTOS (id_producto)
);

Aprovechando la pregunta ;).

Gracias.

[newtron]

Hola.

O yo no me he enterado o no has pillado bien la idea.

Lo que te comentamos es que tengas dos tablas independientemente de las tablas de ventas, una para la tabla de artículos y otra tabla para almacenar los distintos códigos de barras que pueda tener cada uno de ellos.

por ejemplo:

ARTICULOS
========
CODIGO DESCRIPCION
010001 LIMPIADOR TAL
010002 LIMPIADOR CUAL
010003 LIMPIADOR PASCUAL

ARTIBARRAS
=========
CODIGO ARTICULO
010001 010001
0841243564879 010001
010002 010002
0842564564124 010002
010003 010003
0846456564564 010003
0844565458454 010003

Este es un ejemplo de una tabla de artículos con tres artículos creados. Deberías de tener una ventana en la tabla de artículos en la que se puedan introducir los códigos de barras asociados al mismo con lo cual al grabar el artículo en la tabla ARTICULOS estarías grabando al mismo tiempo en la tabla ARTIBARRAS un registro con el código interno del artículo repetido en los campos CODIGO y ARTICULO y otro más por cada uno de los posibles códigos de barras apuntando igualmente al código interno del artículo.

En el proceso de venta, cuando leas un código de barras deberás ir a la tabla ARTIBARRAS y buscar ese código de barras en el que te encontrarás el código interno del mismo en el campo ARTICULO para después buscar en la tabla de ARTICULOS por ese campo para poder leer los datos que te interesen de ese registro.

El insertar un registro con el código de barras y el código interno repetidos es para poder comprar y vender ese artículo bien por el código de barras o por su código interno puesto que estarán los dos en la tabla y podrás localizarlo por uno u otro.

Saludos

[anubis]

Gracias por responder y tenedme paciencia porque me lio solo ;).


Entonces, si entiendo bien, a las tablas que ya he creado, tan solo tengo que crear una mas

CREATE TABLE Codigobarras
(
id_barras integer not null
codigoproducto varchar(20),
id_producto integer,
primary key (id_barras),
foreign key (id_producto) references productos (id_producto)
);



Y usar esta para localizar mas rapido?, porque lo que no veo que codigobarras lo uses como primarykey en artbarras.

[anubis]

No se si entendi bien entonces, en la tabla artibarras si puedo usar el codigo de barras como primary key?.

Gracias y perdon por no entenderlo :(

[newtron]

Hola de nuevo.

La idea de usar una nueva tabla para los códigos es para que pueda guardar distintos códigos de barras por un único artículo, ya de paso, y si quieres, puedes poner el campo de código de barras como primary key.

Si te haces la idea, de esta manera podrás guardar en esa nueva tabla un número ilimitado de distintos códigos de barras para un único artículo lo cual te solucionará el problema de tener solo un código de barras asignado por cada artículo.

Saludos

[Casimiro Notevi]

Además de todo lo comentado, es una mala idea poner como primary key un código de barras porque muchas empresas, para ahorrar costes, usan el mismo código para distintos artículos.

[anubis]

Gracias a todos.

Lo de tener un mismo codigo de barras para diferentes productos, estaba pensando que, en un supermercado, los productos llevan el codigo de barras ya directamente de fabrica, al pasarlos por el escaner sale ese producto y la cajera no tiene que hacer mas.

Lo que me comentais, ya independientemente de que me quedo claro que no voy a usar el codigobarras como clave primaria (Gracias), en esos casos que sea el mismo codigo de barras, imagino que salga una lista en pantalla con los productos asociados para que elijas el que te interesa si es correcto?.

Perdonad que sea un poco obtuso :(.

[Casimiro Notevi]

Tienes la tabla de artículos con los campos:
id integer not null primary key autoincrement
descripcion varchar.....
etc.

Y ahora tienes una tabla de códigos de artículos:
id integer not null primary key autoincrement
id_articulo /* este es el id en la tabla de artículos */
codigo varchar(... /* este sería el código, así puedes tener varios códigos para un mismo artículo */
...
Puedes tener un índice único compuesto id_articulo + codigo (así no habría repeticiones para un mismo artículo y sí podrían haber otros artículos con un mismo código )

En las búsquedas, cuando el usuario teclea un código o lo lee mediante un lector de códigos de barras, tú buscas el código en esta segunda tabla y entonces coges el id_articulo que te indicará a qué artículo de la tabla artículos pertenece.

[newtron]

A ver.....

Creo que nos estamos perdiendo un poco.

Un código de barras JAMÁS debe de estar duplicado con el de otro artículo, en ese caso perdería toda su utilidad. El código de barras debe de identificar a un único artículo para que al leerlo se posicione de forma automática en el artículo determinado sin necesidad de intervención alguna por parte del operario.

Lo que si es posible, como ya he intentado explicar varias veces, es que un artículo pueda tener distintos códigos de barras y que al leer uno u otro busquen el mismo artículo.

Saludos

[roman]

Un código de barras JAMÁS debe de estar duplicado con el de otro artículo, en ese caso perdería toda su utilidad.

Money is money, así que si una lata de sopa cuesta lo mismo que un crema para afeitar, pues podemos usar el mismo código, ¿que no? :p :D

// Saludos

[Neftali [Germán.Estévez]]

Un código de barras JAMÁS debe de estar duplicado con el de otro artículo, en ese caso perdería toda su utilidad. El código de barras debe de identificar a un único artículo para que al leerlo se posicione de forma automática en el artículo determinado sin necesidad de intervención alguna por parte del operario.

Aunque en teoría esa afirmación es correcta, en la práctica no siempre se cumple.
Para obtener un código de barras se debe "pagar" un dinero (cómo no), así que hay empresas que asignan sus propios códigos de barras de forma no-estandard.

[anubis]

Gracias por las aportaciones, me estan sirviendo de mucho.

Si bien decis que no se puede duplicar un codigo de barras y aun que asi fuera por lo que comenta Neftali, puede que si haya duplicados, cuando escaneas el codigo de barras de una lata de sopa, por ejemplo, si ese codigo esta asignado a mas de un producto, solo tendria que salir en pantalla para elegir cual es.

De la otra forma, varios codigos de barras para un solo producto, ahi como decis, es transparente para el usuario porque ya estan registrados.

en ultima instancia, si queremos evitarnos todo esto, generariamos nosotros mismos nuestro propios codigos de barras, pero no es la cuestion.

Gracias de nuevo.

[Casimiro Notevi]

Realmente sí que hay artículos con códigos de barras iguales, los mismos códigos, porque la empresa no se ha querido hacer el gasto en otro o porque reutilizan un código de un artículo que ya está obsoleto y no lo venden. Lo he visto muchas veces y con empresas "famosas". Pero eso solamente suele ocurrir en productos de una misma empresa.
Si 2 artículos tienen el mismo código, pues tendrás que mostrarlos para que el usuario seleccione el que sea. O mejor todavía, al darlo de alta deberías de haber comprobado que no existía. Si ya existe entonces deberías crear un código propio para ese artículo y sacar las etiquetas para pegarlas.

[newtron]

Efectivamente hay empresas que "pasan" de pagar por registrar el código de barras y usan uno propio, yo lo hago en muchos de mis clientes, pero esos códigos de barra son siempre para uso particular, o sea, yo lo etiqueto procurando no duplicar con otro artículo, lo pongo en mi estantería y luego lo vendo.

Por otro lado dudo mucho que en una gran superficie, supermercados, etc. te vayas a encontrar dos artículos distintos con el mismo código de barras porque son códigos de barras registrados y, en teoría, no hay otro artículo con el mismo código. Yo particularmente en veinteymuchos años no he visto esa situación.