Books and books lack database literacy. That sounds blunt, but it is the plain answer. A book can describe databases, teach database design, or explain search habits, yet it does not itself have the structure needed to search, filter, update, or connect records the way a database does.
I keep this distinction close because it is easy to blur. People often say “book” when they mean a catalog, a collection, or a searchable site full of book records. Those are not the same thing. A book is a fixed work. A database is a system for storing many records in a way that can be searched and sorted.
That difference matters most when books are used as sources about books. A printed or ebook title can give advice about metadata, cataloging, or search terms. It can even explain how library records work. But the book itself is not the database. It does not hold live records that can change. It does not expose fields for author, subject, edition, language, or ISBN unless someone has built a separate data system around it.
I see the same problem in search teaching. A learner may open a book and expect it to behave like a database. They may want to search every mention of a word, every edition of a title, or every linked record for an author. A book can support some of that only in narrow ways, such as a table of contents, an index, or a full-text search layer in a digital reader. Even then, that is a search tool attached to the book, not the book itself becoming database-aware.
The most useful fact here is simple. Database literacy is about understanding records, fields, and search rules. A record is one item in a set. A field is one piece of that record, like title or date. Search rules shape what can be found and how. Books can explain these ideas, but they do not perform them on their own.
This is where the project work matters. In database reviews and source notes, I try to keep the source type plain. If something is a book, I say so. If it is a book database, I say that too. If it is a catalog, an index, or a digital collection with book records, I treat it as such. The label is not cosmetic. It changes what the source can do and what kind of claim it can support.
Books are also weak at showing their own limits. A database often leaves traces of its scope in fields, help pages, or export options. A book cannot update itself when coverage changes. It cannot tell the reader that a field is incomplete or that search behavior has shifted since publication. Once printed, its account is frozen. That is useful for some kinds of teaching, but it is a real limit for source evaluation.
There is another honest limit here. A book about a database may be accurate when published and still be out of date now. Search systems change. Interfaces change. Metadata rules change. Some book publishers and some digital platforms describe those changes well, but many do not. So a book may be a useful map, while still missing the current shape of the ground.
This is why I do not treat books as evidence that a database is well described. They are often evidence that someone tried to describe it. That is useful, but not enough. For research teaching, the better question is not whether a book mentions a database. The better question is whether the source lets the reader see how the database is built, what it covers, and where its gaps sit.
That also means books can mislead by simplification. A clean explanation can make a messy system seem stable. A database may look simple in print and still be uneven in practice. Search can be broad but shallow. Metadata can be rich in one field and thin in another. A book may flatten those differences to make the topic teachable. I understand why that happens. I also want the limit named.
So the answer stays the same. Books and books lack database literacy. They can teach it, comment on it, and model it in part. They cannot replace the live structure of a database, and they cannot guarantee current truth about one. That is the line I want readers to see clearly.
The Source List fits that same need for plain speech: one digital source worth knowing, one search tip, and one honest limitation. That is the right size for the problem.