A database stores information as records, one for each thing it keeps track of, such as an article, a course or a person. Each record holds the same details in named fields. Because every record follows the same pattern, you can ask questions of the whole collection at once, such as which descriptions haven’t been reviewed this year or which courses a particular provider runs.
Records can also point to one another. Each course can link to its provider’s record instead of repeating the provider’s details, so a correction made once reaches every page that draws on it.
That’s the difference from a folder of documents, where the details sit inside each file and someone has to open them one by one to find out who owns what. A spreadsheet comes closer: each row can be a record and each column a field. But it will accept anything in any cell, and connecting a row to one on another sheet takes formulas that somebody has to keep working.
A database can insist that a status comes from an agreed list, that a date is a date and that every course has a provider. Notion and Airtable work this way, and so does the storage behind most content management systems (CMSs). In each case the structure matters more than the product: which details get their own field, how records relate and what people need to find or change.
Why it matters for content
Storing content as records changes the work of writing it. Instead of composing a page, an author fills in fields: a title of a set length, a summary, a body, a start date, a link to the right provider. The same course description can then appear on the course’s own page, in search results, in a printed prospectus and in a partner’s listings, and one update to the record changes all of them. Audits get easier too. A question like “what hasn’t been reviewed in two years?” becomes a filter rather than a week of opening pages.
The cost is that writers can lose sight of the finished thing. A form full of fields shows none of the pages it will feed, so a summary that reads well on its own may sit badly beside an image or get cut off on a phone. Good systems give authors previews and guidance for each field.
The structure also hardens: once templates, feeds and reports depend on a field, renaming or splitting it means changing all of them. That’s why decisions about fields and relationships belong in content modelling, with content people in the room, rather than being left to whoever builds the system. And a field nobody fills in, or fills in inconsistently, is worse than having no field, because people and systems will trust it anyway.
How AI changes the picture
Structured records let an assistant give exact answers to some questions. Asked which courses start in March, a system that can query a start-date field returns a list; one that has to read course pages is guessing from whichever passages it finds. Fields for status, owner and review date can also keep withdrawn or expired material out of an answer, provided the retrieval is set up to use them. None of this makes a stored claim true. An out-of-date description in a well-labelled field is still out of date.
For questions that don’t map onto fields, systems increasingly search by meaning. A vector database, or a vector index added to an ordinary database, stores each passage as a long list of numbers, called an embedding, that places it near passages with similar meaning.
Graph databases, which store connections between people, topics and organisations, can help a system follow relationships that the text only implies.
AI can also help with the slowest part of building a content database: getting existing material into it. A model can propose summaries, tags and content types across thousands of legacy pages far faster than a person could, flag records where the fields contradict the body and spot a field that’s doing two jobs. People still need to check its proposals, and reviewing a sample shows how far to trust each kind. But a structure that once needed months of manual migration can now be filled well enough to start using, then improved as it’s used.
Questions people ask
- Where do we start?
With content you already maintain over and over, such as events, courses, products or policies. Pick one type and list the details people look up, display or change. Those are your candidate fields. Add a relationship only where a real change needs to travel, such as a provider’s new address reaching every course. Then enter twenty real items before committing: gaps and awkward fields show up fast.
- How many fields should a content type have?
As many as someone uses to find, display, check or reuse the content, and no more. Each field needs a person who fills it in and a reason someone or something reads it. Splitting a body into many small fields makes reuse easier but writing feel like form-filling; one large body field is pleasant to write in and hard to reuse. Writing three real items is the quickest way to find the balance.
- Do content people need to understand technical databases?
They don’t need to become database engineers. They need to understand enough structure to ask better questions: what are the content types, what fields matter, how do items relate, what needs to be reusable and which source is authoritative?
- How does a database relate to a CMS?
A CMS often uses databases behind the scenes to store content and metadata. Content teams may never touch that database directly, but their content model, fields and workflows determine whether the system is useful or awkward.
Learn more
- Content Modelling: A Master Skill – Rachel Lovinger on documenting content types, their attributes and relationships, and keeping that model as a living reference shared by designers, developers and authors.
- Embeddings: What they are and why they matter – Simon Willison’s explainer on finding content by meaning, built around a related-posts feature for his own site; he argues an existing database with a vector index often does the job without a specialist vector database.
- Database as a Symbolic Form – Lev Manovich’s 1998 essay on how collections, interfaces and narrative shape different ways of encountering material.