Cita: si tengo que agregar algun campo para que acepte el lector de codigo de barras,,,,,,
Estás perdiendo un poco lo que dije: El hecho de que una aplicación use o no un lector de códigos de barra,
a la base de datos no la afecta. Directamente no le interesa, porque un lector de códigos de barra es en realidad un conversor de caracteres (más exactamente, trabaja con una interfase programada que transforma los objetos escaneados en caracteres), y lo que ingresa a la base no es el código de barras, sino el número que ese código está expresando... Y eso es simplemente un campo más en la tabla Stock, Artículos , Productos o como quieras llamarla.
El resto, es asunto del programa, no de la base.
Piensa la secuencia de este caso de uso (rudimentario):
Cita: 1. El usuario activa el lector.
2. El usuario pasa el lector sobre el código impreso.
3. El lector lee el código impreso.
4. La interfase decodifica la imagen escaneada.
5. La interfase envía al programa un flujo de datos conteniendo señales de inicio, bloque de datos y señal de fin.
6. El programa, por sus librerías, descarta las señales, recupera el conjunto de datos y lo almacena.
7. El programa consulta a la base el contenido de datos de un producto identificado con la PK obtenida del conjunto de datos recibido de la interfase del lector.
8. La base de datos devuelve el registro de datos del producto.
9. El programa usa la información recibida para representar los datos del producto.
En todo esto, la base lo único que recibe es una clave primaria... nada más.
Con esto quiero que quede claro lo que te dije antes: Usar un lector de barras, o ingresar el número por teclado (lo habrás visto en los supermercados), paa la base es lo mismo, porque la base recibe una PK, no un código de barras. Que la PK sea creada sobre la base de un EAN-13, un ISBN o cualquier otro, es un problema de diseño de la tabla, pero en cualquier caso sigue siendo un campo VARCHAR.
Para que se entienda lo que la base tiene que guardar, mira esto:
EAN-13:
DUN-14: EAN/UCC-128 (SSCC):