The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Bar Code Tech.

I am writing an application for library system using SQLServer2005 & VB.NET. I intend to use bar code technology for the first time. I come across a problem is that if I have 10 copies of specific item "Book". I am not sure which primary key should I pick is it BookID as uniqueidentifier type or ItemBarCode , however, if I picked the ItemBarCode it will not be unique key because there are many copies of an item. It might be a naief question but still I need your help!
thanks.
Mag
Mag Send private email
Saturday, January 05, 2008
 
 
Well, which do you care about?

The absolute number of a given Book?  For example, you want to know that you have 5 copies of Hunt for Red October and then sell one and now have four.  In that case, you're not tracking the individual items, but the items in aggregate.  You don't need each book to be unique.

The specific object of a Book?  For example, you're a library and you need to know that Joe has this copy of Hunt for Red October vs Mike having a different copy.  In that case, you don't *care* that they have the same book content, just that they each have a physically unique book.

Clancy... that's what I get for reading a book about HRT right before bed.
KC Send private email
Saturday, January 05, 2008
 
 
Forgetting about the barcoding aspect for a moment, how would you uniquely identify each copy?
You're not paranoid if ...
Saturday, January 05, 2008
 
 
Thanks for your responses
I still need to track down the copoies as if the system lended a copy to Tom and other copy to Joe. I need to know who borrowed my stuff. Still waiting for your input thanks!
Mag
Mag Send private email
Sunday, January 06, 2008
 
 
Then you create your owm barcode or codimg system, cos the ones supplied on the back of a book ain't unique per book :)

Sunday, January 06, 2008
 
 
I'm not trying to slam you but this is pretty basic stuff.  Consider that you may not be qualified to design and develop such a system.
Anonymous Hippopotamus
Sunday, January 06, 2008
 
 
Create a surrogate key because, theoretically, not all the books are the same.  One might have the old cover, one might be in rough condition, etc.

I'll tell you one thing I learned in my first few weeks working at Amazon -- publishers reuse ISBNs and bar codes occasionally, so be careful using them as identifiers if you care about collisions.
anon
Monday, January 07, 2008
 
 
Mag, do some research into Inventory Management.  This forum isn't for learning/implementing basic concepts... the value of these forums come from questions like:

"I have option A and option B.  If I use A, I can do X, Y, and Z, but I have concerns about....  And if I use B, I can't do this stuff, but I can do these other things."
KC Send private email
Monday, January 07, 2008
 
 
People come here to learn.  So ... teach them.  Don't stone them because they're not experts.

Mag,

You need four tables:

Items - ItemID unique and other things to describe each book title.

ItemInstances - ItemInstanceID, and relates to Items on ItemID.  Also whatever other things required to describe an individual physical book on your shelf - perhaps "date purchased" and "purchase price".

Borrowers - BorrowerID unique and other things to describe one borrower.

BorrowersItemInstances - links Borrowers to ItemInstances and includes fields like BorrowedDate.

You might want a BorrowHeader if people borrow many things at once.  In that case BorrowersItemInstances becomes BorrowDetails and then BorrowHeaderID links to BorrowDetails to create a one-header/many-details transaction set.

The ItemInstanceID field in ItemInstances will be your barcode.  You'll print one bar code for each individual physical book in your library.

HTH.
Karl Perry Send private email
Monday, January 07, 2008
 
 
"People come here to learn.  So ... teach them.  Don't stone them because they're not experts."

But your answer didn't teach the OP anything - you just gave him part of the answer for his school homework.  If you wanted to teach him something you should probably explain your reasoning and not just your solution.

Also, this either has to be a homework project - there are too many free/cheap library systems for someone to decide to write one (especially if they don't have any domain knowledge).
RocketJeff Send private email
Monday, January 07, 2008
 
 
s/this either has/this has/
RocketJeff Send private email
Monday, January 07, 2008
 
 
Karl,
Thanks a lot for your help. I appreciate it
Mag Send private email
Friday, January 11, 2008
 
 
+1 to Karl

also don't use meaningful data such as ISBN numbers or SSN's (in the case of people) as id's.  Have the database create a non-meaningful unique id either a unique integer or guid (if you are concerned about replication) and then have the ISBN number as a separate field.  This is important because however unlikely it may seem, ISBN numbers and SSN's and "meaningful" data can sometimes change and if it does you only want to change it in one place, not across many tables.  Use the "non-meaningful" generated id for linking to other tables.
Steve Massing Send private email
Thursday, January 17, 2008
 
 
This "meaningful data" idea is more general principle so will find exceptions and I am sure many will note them after this comment :-), but it is a good practise that has saved me many times.  It also serves as an "extension point" for later unexpected needs.  I also add "CreatedOn" and "LastUpdated" Date/Time fields to most of my tables and that has also served me well for future reporting needs.
Steve Massing Send private email
Thursday, January 17, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz