According to my teacher you should better store the ISBN of a book into an int than in a String.

Personally I agree with you String is better.
But you can also use an int.

that's arguable

If the number is longer than four digits and won't be used for anything mathematical, I'd use a string.

No reason it should be an int. If you are not doing math then store as a string. Go to your teacher and ask what kind of math are they going to use with a isbm?

@IllSlapU because no Mathematics are going to be use its why people store zip codes as strings. Sure you can make it an int but why? There is no value in doing do. It's safer and better design to store as string.

@IllSlapU but, ISBN can have some '-' in it and can be longer than max value of an int...

So this teacher apparently hasn't been taught foundational programming?

ISBN is NOT a number ffs.

What would your teacher do, if the ISBN had leading zeros, "-" or's a little bit longer? wtf

Doesn't ISBN contain letters?

Why not store it in text 😝

Defenately string because ISBNs can have leading zeroes if I'm not mistaken. Storing it as int would drop those and thus muddy the value.

String, are you by any chance in 10th grade of academic highschool (gymnasium)? :)

Title*

If its a number then its suitable to be integer

Strings are better for doing like operations.@kxspxr

Yep - ISBNs sometimes have an "X" in them

First like for you 😊 @alexalexalex09

@superadmin I'm German. Titel is the German Word for Title ;)

Ooh my bad.. @EaZyCode

@404response Yes I am and it's pretty boring until now...

Because isbn used to be primary key in db so it makes sense to have as int for that case. Otherwise store as string and if need cast to int inside code. Same with regex on postcode if you need order on postcode or todo something else you need make it is stored always for all records using specific format otherwise go for string with simple validation for string inputs

@EaZyCode me too, we did the same thing but my teacher also says that it should be a string :)

@rim01 So your primary key in a table is going to break first normal form by not being atomic?

I'm on the "string" side of this argument. That will allow you to accept ISBNs of various specifications (and two of which have been mentioned thus far). You then roll out new strategies as new formats are ratified by whatever agency controls ISBNs.

If that agency should decide that an ISBN should contain a non-numeric value, you're toast.

And an addendum:

I know the 'N' in ISBN should mean "number". Yet it's a specification outside of the developer's control. You may assume that 'N' is a promise, but judging by the people mentioning that there used to be an 'X' in that "number", I wouldn't hedge the longevity of my code on that promise.

ISBN is 10 letters where checksum can be an X and what is commonly called the ISBN is the EAN and is 13 digits usually starting 978 for books. The 10 character isbn was phased out a few years ago although it is still used unfortunately

Also adding... isbn would not make a great primary key an isbn although unique to the title and the publisher it could exist within multiple publishers as occasionally rights are brought or some other arrangement is made then ebooks further complicates this as electronic versions can be released on the same isbn

we store both isbn10 and the ean (isbn13) as.. drumroll please... strings.. I’d happily email your professor and explain why this is the case. In .edu they are also documented as strings not numbers

1. Yes you will do math with ISBN, ISBN13, EAN, IBAN, SSN, etc

2. You should validate numbers like these when creating forms. ISBN uses a MOD11 checksum.

3. You should generally handle as string, because the math requires you to split per character anyway. Just fail input validation when there are unexpected characters.

@xorith it is not my primary key I am just saying what I saw in some legacy systems... I am personally using primary key incremental integer ...

But look at the bright side she didn't get offended by the wrong spelling of title 😛

It could be either one. The problem, professors will takes points off or even mark you wrong when your answer doesn't meet their requirements. This prof most likely prefer int instead of explaining it to the students, they'll claim int should be used no matter what.

both work but I'd go with a string since most likely storage ain't an issue

@drekhi12 It's a German test so Titel is the correct Word. Although I would prefer it to write that in english.

Store it as boolean

@pavel-durov mind = blown

And also according to your teacher writing code on paper is a great idea. 👎

@EaZyCode in theory you could store it as int and have getters and setters to fix the leading zero, and other formatting issues. However it is by no means wrong to use it as a sting (for simplicity sake far better even) teach should never have "corrected" this.