What a database is
A database is an organized collection of information that a program can store, search and update reliably. The software that manages it is usually called a database management system, or DBMS. People often say “the database” for both the data and the software that looks after it, and in everyday IT conversation that is fine.
Think of a paper filing cabinet. Folders hold records, labels make things findable, and a clerk knows where everything lives. A database does the same job for a program, but it can handle far more records, serve many users at once, and answer questions in a fraction of a second.
Why applications rely on databases
Almost every application needs to remember things after it is closed. An online shop remembers products and orders. A help desk system remembers tickets. A banking app remembers balances. Keeping that information in the program’s memory would lose it the moment the program restarted, and keeping it in loose files quickly becomes unmanageable.
A database gives an application several things it would otherwise have to build itself:
- Durable storage. Data written to the database is meant to survive restarts and, with proper setup, many kinds of failure.
- Fast lookup. The database can find one record among millions without reading everything.
- Shared access. Many users and programs can read and change data at the same time without overwriting each other’s work.
- Rules. The database can refuse data that breaks the rules, such as an order that points to a customer who does not exist.
- Security controls. It can decide who may read or change which data.
How a database fits into a system
Most databases run as a separate service on a server. If you want a gentler primer on what that means, server basics covers the idea of a machine that provides a service to other programs. The application, called the client, sends a request to the database, and the database sends back an answer. The user of the application rarely sees the database directly.
Requests are usually written in a query language. For relational systems that language is SQL. Many web applications also reach their data through an interface that sits in front of the database, which is where API basics comes in: the app talks to the interface, and the interface talks to the database.
Main kinds of databases
Databases differ mainly in how they organize information.
Relational databases store data in tables made of rows and columns, with links between tables. They suit structured information such as customers, orders and invoices, and they are the most common type in business software.
Document databases store each record as a flexible, self-contained document, often resembling a structured text file with fields inside it. They suit data whose shape varies from record to record.
Key-value stores work like a very large dictionary: you give a key, you get back a value. They are simple and quick for things such as session information or settings.
Graph databases focus on connections between items, which helps when the relationships are the main point, such as a network of people or devices.
Each type has trade-offs, and many organizations use more than one. The differences between tables and the flexible alternatives are explored in a separate comparison of relational versus NoSQL approaches.
Keeping data correct
Databases are designed to protect correctness. A common idea is the transaction: a group of changes that either all succeed or none do. If a payment moves money out of one account and into another, a transaction ensures you do not end up with the money removed but never added. This is often summarized by the word ACID, which stands for atomicity, consistency, isolation and durability. You do not need to memorize the term to benefit from it, but it explains why serious applications use proper database software instead of homemade files.
Constraints add another layer. A column can be required to be filled in, a value can be required to be unique, and a link to another table can be required to point to something real. Catching bad data at the door is much easier than cleaning it up later, although messy data still turns up in practice and needs cleaning before analysis.
Looking after a database
A database often holds the most valuable information an organization owns, so a few habits matter.
Backups. A sensible backup strategy covers databases explicitly, because copying the files of a running database without the right method can produce a copy that cannot be restored. Whatever the method, it needs to be tested.
Access. Only the people and programs that need the data should reach it. Applications typically use accounts with limited permissions, and the idea behind access management applies as much to a database as to any other system.
Encryption. Sensitive data is often protected with data encryption, both when it is stored and while it travels between the application and the database.
Personal information. If a database holds personal data, the organization usually has legal and ethical duties around how that data is kept and used. These duties vary by place, so the details are worth checking with the right people.
Updates and monitoring. Database software needs regular updates, and someone should notice when it slows down or runs out of disk space.
Databases, spreadsheets and storage services
Beginners often ask whether a spreadsheet is a database. A spreadsheet can hold a list of records, and for a small personal project that may be all you need. Problems tend to appear when several people edit at once, when the data grows large, when the same information is repeated in many places, or when rules need enforcing. A database handles those situations far better.
A database is also different from general file storage. A folder of documents, whether on a local disk or in cloud storage, holds files as whole objects. A database understands the content inside its records and can answer questions about it, such as “which orders from last month are still unpaid?”
Where to go from here
You do not need to run a database to understand one, but trying a small one makes the ideas concrete. A good order is to learn how tables, rows and keys work, then write simple queries to read data, then learn how to combine tables and how to structure them to avoid duplication. Later topics, such as indexes for speed and data warehouses for analysis, make more sense once those basics are comfortable.