Quote:
Originally Posted by hydraMax
There are always three dashes in an ISBN-10 ID, and four dashes in an ISBN-13 ID, correct?
|
No. An ISBN is actually a 3 or 4-component vector with integer components and an additional single-digit checksum. The components may be separated by spaces or dashes.
Quote:
Originally Posted by hydraMax
I'd prefer to store them as integers instead
|
Feel free to do that. Actual ISBNs are unique without the separators. They have to be, since the barcode does not contain the separators, just the numeric value. You can reconstruct the separators, but it's usually not worth the hassle.
Unfortunately, the last digit in the ISBN code may be X instead of a digit. Since it is just a checksum, it is derived from the other digits; you probably should store it separately. When searching, you can ignore the last character altogether -- Amazon does.
Note that if you store ISBNs as a vector, searching using a partial ISBN is next to impossible. Well, you can get your database to do it for you, but the cost in CPU time and memory use is not worth it at all.
Personally, I'd store ISBNs in two or three related fields:
- Unique integer part
(Omitting the checksum character and separators)
- Optionally, the integer part as a string
- As a string of up to 17 characters (or more)
(Used only for display purposes)
The first one is unique for each book. I'd use it as a key. If your DB supports binary integers, you might wish to have a copy as a string, so that you can do partial ISBN searches. The last one, the string representation, is used for output purposes only; never for searches or selection. Obviously, your frontend should derive all from the same input.
