this is a cool proof of concept but i dont really see the use of this but its a good app, now maybe supermarkets will put psp in the store
Printable View
this is a cool proof of concept but i dont really see the use of this but its a good app, now maybe supermarkets will put psp in the store
That's about right, but if you do have those full product databases from a few companies you canQuote:
Not really.
On a technical side, bar codes on products dont store any information apart from their number. The number is used to look up information in a database (hash-tables, direct look-ups, etc) to find out their associated product name, price or what have you. (Sort of mentioned on his website).
So, in other words, if you walked around a store scanning stuff, you wouldn't get anything (apart from the number) unless you have the entire stores inventory database stored in your PSP somewhere or wireless accesst to the database on the stores network...
start to have some fun finding who is cheapest
on certain items, etc.
A lot can also be done with stocktaking data.
Art.
what a wierd idea, very awsome though and i will most deffinantly get this
Out of curiosity, how big on average would a companies product database be though?Quote:
Originally Posted by Art
o_o HUGE. I work in Target doing backstocking, so I spend about 8 hours a day scanning items. There are literally thousands of different items and barcodes. You must also consider that they keep information on older items not currently in stock (though these are eventually purged.. I've encountered it a few times when we have an old item that was never sold, barcode purged, and the computer has no clue what it is). I don't imagine that the database would be some sort of impossibly huge file (especially since there isn't alot of information on each product), but it definitely would be big.Quote:
Originally Posted by Vylen
Soo.. yeah. Tons and tons of barcodes. o_o
Probably not that big at all. All they have to do is associate the string of numbers with the product. They just scan an item when its new and type in all the information for what they want to call it. I want to try it out since I have access to a ton of barcode readers. Working in a laboratory they have them to map speciman in racks and print out extra labels to attach to them. I dont do that stuff but I setup everything since Im there computer guy. It makes me wonder if I could get a label printer hooked up to the psp as well so you could scan a barcode and have it print whatever you scanned. But of course this would take a whole seperate program coded to do that.
Quote:
Originally Posted by cloud_952
Depending upon what software you are using could determine the size of the database but I would not think that it would be very big even with thousands of items since its a very simple code to have an item mapped to a specific barcode. Maybe if they use something like SQL that database may grow to a pretty big size.
While it's true (that it shouldn't be too big), Target (and likely alot of other places) associates quite a bit of information and cross-referencing with each barcode. Not only does it locate the item, but depending on which menu you're in (which program you're running), it pulls up different information.Quote:
Originally Posted by VFerg
So, basically, the information stored on each item (from what I've experienced, there could be even more that I've never encountered) is: in-store location, backroom location, current price, sale price, Target item number (DPCI), and UPC (SKU, barcode, whatever you want to call it). So.. it really does take a little more than just the scanning and a simple barcode + info. Though, it really depends on what you intended to do, I guess.
o_O I think most of the information is processed server-side (the cross-referencing) before being submitted to the end-user (me, the stockboy). Though all that information would have to be located on the PSP, and the PSP would have to process the info and cross-reference the information, too. ^_^; Ouch.
But that's just for Target, and likely many other large stores. For anything else and smaller, I'm sure alot's doable.
.. and don't forget the Human readable description :D The most memory wasting field of all.Quote:
So, basically, the information stored on each item (from what I've experienced, there could be even more that I've never encountered) is: in-store location, backroom location, current price, sale price, Target item number (DPCI), and UPC (SKU, barcode, whatever you want to call it). So.. it really does take a little more than just the scanning and a simple barcode + info. Though, it really depends on what you intended to do, I guess.
Yes that's most of what is contained in the stock files I've seen.
There is also a few possible extras like carton quanities, or pallet quantities in the case of a warehouse.
Actual inventory levels are in a seperate file.
It would probably be fair to say smaller than you think.
Say 16Mb for 22,000 product records.
Target might have more items than that ranged into
their stockfile, but compression is doable by stripping out fields you don't need.