Re: Barcode databases - the issues

["mark_harrison_uk2" <mph@xxxxxxx>]

Maybe I'm missing the point here, but what is the purpose of doing=20
this.

To say that I can scan a product and find out what it is... well, if=20
I look at the product I'm holding, I can see as well ?

Is the intended application something like "scan every food product=20
you throw into the bin, and at the end of the week, print out a paper=20
list of what you've thrown as a shopping reminder"?

If that's ALL the expected use, then a "free format" on what
things=20
are called would be fine. Otherwise, we need to work a little harder=20
on consistency.

It's sort of like the "MP3 genre tags" problem with CDDB... I=20
say "rock", you say "prog rock", he says "70s
rock"... this is=20
why "play by genre" is always confusing unless a single person
has=20
genre-tagged, and why things like TagAndRename are so popular.

By all means, send me over the schema and I'll take a look.

Regards,

Mark

--- In ukha_d@xxxxxxx, Stuart Grimshaw <stuart@s...> wrote:
> On Saturday 11 Oct 2003 1:32 pm, mark_harrison_uk2 wrote:
> > Here we go again :-)
>=20
> and with two of the same people, you would have thought we'd=20
learned :-)
>=20
> > It's easy to get into a "it's trivial to build a barcode=20
database",
> > but unless we work FIRST to determine what the data will be
used=20
for,
> > there is a real danger that the data will be fundamentally
stuffed
> > since there's been no definition of integrity requirements.
>=20
> The idea is to store just barcodes and info on the products they=20
relate to,=20
> nothing more nothing less. Give it a barcode, it tells you what it=20
is.
>=20
> Any other functionality will be down to whoever is using it, re-
order levels,=20
> recipe suggestions etc will be down to individual=20
authors/applications.
>=20
> > For example, an obvious thing to do would be to query
"what's the
> > barcode for a can of coke", or "what's the barcode for
organic=20
milk".
>=20
> It would normally be the other way around in this instance, since=20
we already=20
> have the barcode, we want to query the DB for a description etc, if=20
there's=20
> no match, then well there's no match, type it in yourself :-)
>=20
> > I've done a fair amount of work on these commercially, for
several
> > employers.
> >
> > The technology side of setting up a database that maps Barcodes
->
> > Product names is trivial.
> >
> > The arguments about whether it's in MySQL, PostGRES, or
SQL*Server
> > are fun, but ultimately pointless. The inherent data structure=20
behind
> > these product databases is SO simple, that any SQL programmer=20
could
> > write a line of code that generates, in turn, a full SQL String
to
> > input all the data back into any of the other databasese.
> >
> > The complexity is in the mapping from Product -> Barcodes, and
the
> > integrity of the data set.
> >
> > At the simplest, level, consider a 330ml can of Coke. Three=20
different
> > people buy one, and scan in the barcode. One of these people has
> > bought a "standard for resale" with a UPC (Universal
Product=20
Code),
> > one has bought a four-pack and scanned one of the cans (with a
> > different UPC), one has bought a co-branded can with a Tescos-
> > operated football promotion with a PPC (Private Product Code).
>=20
> Do they tend use the category digit at the start of the barcode (5=20
is it for=20
> private barcodes) or do they just stick to the standard 0 ?
>=20
> > Two of these three enters "Coke", one enters "Coca
Cola" as the
> > description. Both enter "330ml" as the size...
> >
> > Going FROM the barcode to the product is trivial for someone
> > interrogating the database.
>=20
> And that's what the database is designed for, if people want to use=20
it to go=20
> the other way around, then fine, but they will run into the=20
problems you=20
> describe.
>=20
> > Going FROM a requirement for a "330ml can of coke" will
turn up 2=20
of
> > the barcodes, but not the third. Even worse, one of the
barcodes=20
may
> > have been for a limited-time PPC, so isn't available any more.
>=20
> I can't think of a situation in the home where you might want to do=20
this, but=20
> I'm open to suggestions ... ?
>=20
> >
> > One of the companies I worked for signed a joint deal with Spar
to
> > share product information. Spar put out a big press release
saying
> > that downloading the product information from their database
had=20
made
> > integration easy. This was rubbish. I had a team of 4 vacation
> > students in the local Spar for a fortnight with barcode
scanners=20
and
> > laptops re-doing everything.
> >
> >
> > Here are some fields for the "product table" in a
database that=20
you
> > might like to consider. Items marked with * are keys on
another=20
table.
> >
> > - Manufacturer * varchar
> > - ItemName varchar
> > - ItemSubname varchar
> > - ItemClassification varchar *
> > - ItemSizeNumber int
> > - Item size char
> > - Organic boolean [default=3D"No" for ease of
inputting]
>=20
> That's roughly what we had, apart from the size char (though I did=20
have=20
> contents for things like 80 Tea Bags, that also have a weight)
>=20
> I can send you the schema I'd come up with if you'd like to cast=20
your beady=20
> over it...