Are product box bar codes suitable for primary keys?

Asked

Viewed 366 times

2

Situation

In a system where products will be stored in the database, and the barcode is a unique field, I would like to know if the barcodes that come in the product boxes have the possibility to repeat themselves with different products. The company works with network equipment, there is an alternative to identify the products by the MAC, but they also work with some products that do not have MAC.

In short

I don’t know anything about the barcodes and the possibility of them repeating.

  • 3

    It depends on the type of bars. If it is all UPC, as is normal in industrialized products, do not repeat. But there are people who use bars for internal control, in this case, complicates. Note that we are talking about unique identification, (two identical products with different code), only making their own labelling system. And Macs can repeat themselves, even though in an ideal world that doesn’t happen, it’s not really like that. Especially if there are several different manufacturers. Not all use the same criteria.

  • Yes, they need to know if an equipment is with an employee, or is in stock, for example. The current control is identified by the MAC address, but they have a problem in identifying the other products that are working, precisely because they do not follow a consistent pattern.

  • 4

    Best thing is to make the company’s control labels. Arrived product, force to label in order to be able to give input. Nobody does anything if you don’t have the serial. With the single serial, you have full traceability. If you can’t open the box, do it in 2 steps. When opening the product, you have to note that it opened in the register of that serial, and note the definitive label (internal). Thus, with future uses of the box label, the system warns "the product has already been unpacked, please use internal label". Of course, these are general ideas. Have to adapt to your reality. The same ideal is unique series tamper proof label.

  • 2

    Instead of trying to find a single string field, why not put a generic integer and auto-incrementable id? If you need to leave the string field as unique, mark it as Unique key, do not put string as the identifier of a table. Imagine if the table has 1 million records the string search is much slower in databases. I know it’s a database rule to "find something that doesn’t repeat itself" and mark it as a key, but what if later you find out that your "that doesn’t repeat" field isn’t quite like that, you’ll create a composite key? I wouldn’t advise you to do that.

  • Thank you @Geferson, but under no circumstances have I considered placing the MAC or ID as the table’s primary key, each record already has an auto-incremental primary key, in the case of this unique identifier that was meant to be the barcode, it is only to avoid duplicate records. I didn’t think composite key, either, but I was thinking about leaving the MAC and the barcode as one. I will talk to the press and suggest the use of barcodes for internal control (codes used only within the company). Thank you, if you have any suggestions will be welcome.

2 answers

3


Product box bar codes are suitable for keys primaries?

To answer the question, no, it is never good to make public the identifier of a bank record. Public information, even if it is unique as a barcode, is usually only associated with UNIQUE constraints in the database that have another internally generated numbering as ID.

1

No even, primary key has to be unique ok, that’s right, but being information that the user can handle puts at risk your entire table. It’s also more optimized if it’s numerical, which I couldn’t do using barcodes.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.