You might want to mention UUID primary keys - they are somewhat controversial, but an accepted solution for artificial primary keys among many, and one way of preventing replication problems.
–
tdammersJun 22 '12 at 14:30

What's the problem with gaps in your database when using IDs from 1 to n?
If you really mind the gaps, you could add new manuals inside those. (In your example the next new manual would get the ID 2, 3, ... , 32, 34).
Or you could save a list/stack of the IDs from the deleted manuals and every time you add a new you pop the next ID from the list/stack. This would save you some time.

Also, an ID is not meant to be meaningful, it's just to have a fast way to distinguish between different manuals, so IDs should be unique.
You said every manual has a name which should be pretty meaningful already and if two manuals have the same name they at least have different IDs.

The definition of "meaningful" or even "not complicated" is far from being objective, IMHO. Also meaningful could very well be dependent on the data you're storing in your db.

As stated by mcwise, the purpose of an id is to be unique and not meaningful. Do you really have to use a manual id ? Auto-generated id prevent you from even knowing there are gaps, and will always ensure ids are unique.

If you absolutely want a unique manual and meaningful ID, try finding either a field that will always be unique in your base (for example emails for users in a web site) or generate one from several fields where you know that the combination will be unique (for example firstname-lastname-birthdate-birthplace)

A human-meaningful identifier and a machine-meaningful identifier can be two separate things - both require uniqueness because of the inherent nature of the problem:

Given X, how can I find the manual I need?

Identifiers should really be given to humans, rather than generated by humans. Humans are bad at creating consistently unique identifiers, but computers are good (or at least quick) at it.

Ideally, you'll have some sort of search mechanism when you are looking for a manual. You won't need to remember some random 16-byte number or QR-Code, because the computer will generate a list of all currently saved manuals for you when you search for "requires assembly" or "batteries not included", and provide links to them for you.

Having said that, it is often an advantage to have a unique key which has no meaning at all. Call it "UniqueID", "MagicKey" or whatever takes your fancy, but be aware that it has no meaning outside of your database. This way, if the meaning of something to do with the manual ever changes in a way you don't expect, you don't have to change the key.

This is why Username is a poor choice for a foreign key in a database. If a user ever changes their Username (if it's based on their surname and they get married, they may want to change it), you have a lot of work to do in your database.

If you chose a meaningless "UserID" instead, and the user changes their username, you only have the change to make in one place, and everyone is happy.

Meaningful and unique hardly coexist in a single place. For me I just use a system generated auto incremental no as ID when it comes to 1000's of records.

In the case of using an incremental number as an ID have an extra field that determines if the manual exist or is being deleted.All you have to do is in the select statement mention another condition in where clause.
Other advantage of using this is you need not bother about what ID is to be assigned to a new manual entry the system will take care of it.
Speaking about he logic to use for assigning ID's it solely depends on the programmer. The logic which is easier for him.

The ID number should be computer generated one-up number. Asking the user to pick a number invites too many problems. There can be a typo, you could skip a number or duplicate a number. You can write software to look for these problems but it is easier to have the database take care of it on record creation.

If a manual is destroyed because it is not longer needed you don't want to recycle the number. Imagine if a somebody had a procedure where it said get manual 7 and complete the task on page 99 so the computer backups can be restored. But manual 7 is now about the smoke alarms, and only has 10 pages. If one is replaced you should have a field telling the user it is gone, and that the updated manual is now number 50.

You will be using the real titles of the manuals as a field in the database. That way when there are hundreds of them they can be searched by key words. Imagine how hard it would be to talk about books if there were no titles, only the ISBN numbers.