What Databases Are and How They Store Information

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 use “database” for both the data and the software around it.

You use databases constantly without seeing them. A store keeps its product list and orders in one. A bank keeps account records in one. A social app keeps profiles, posts and messages in one. When a page loads your order history, a program is asking a database a question and formatting the answer.

Why not just use files?

You could keep information in a folder of text files or a single spreadsheet. For a small, personal list that is often fine. Problems tend to appear as things grow:

• Duplicates drift apart. If a customer’s address is typed into ten files, one copy gets updated and the others do not.
• Searching becomes slow. Scanning every file for one name takes longer as the pile grows.
• Two people edit at once. Without rules, one person’s change can silently overwrite another’s.
• Mistakes slip in. Nothing stops a phone number from being typed into a date column.

A database is designed to handle these problems: it keeps one agreed copy of each fact, finds things quickly, controls simultaneous changes and checks that entries follow the rules.

Tables, records and fields

The most common style, the relational database, stores information in tables. A table looks like a spreadsheet grid, but with stricter rules.

• A table holds one kind of thing, such as customers or orders.
• Each row, also called a record, is one instance, such as a single customer.
• Each column, also called a field, is one attribute, such as name or email address.

Here is a small hypothetical customers table:

Every column has a declared type, such as whole number, text or date. The database can then refuse a value that does not fit, which keeps the data cleaner from the start.

Keys connect tables

Notice the customer_id column. It is a primary key: a value that is unique for each row, so a record can always be identified without relying on a name that two people might share.

Now imagine an orders table in the same hypothetical shop:

The customer_id column here is a foreign key: it points back to a row in the customers table. Instead of copying Ben’s name and city into every order, the orders table just stores the number 2. If Ben moves, you change his city once, and every order still points to the right person. Splitting information into related tables this way is often called normalization, and its main goal is to store each fact in only one place.

How you ask questions

Most relational databases are queried with SQL, a language for describing the result you want rather than the steps to get it. A request such as “list the items ordered by customer 2” is translated into SQL, and the database works out how to find the rows. The differences between this style and newer alternatives are covered in the comparison of SQL databases and other approaches.

Indexes make searching fast

Without help, finding one row means checking every row. An index works like the index at the back of a book: a separate, sorted lookup structure that points to where each value lives. With an index on a column, the database can often jump to the right rows quickly instead of reading the whole table.

Indexes are not free. They take extra space and must be updated whenever data changes, so they are usually added to the columns people search most often rather than everywhere.

Keeping data trustworthy

Databases are built around the idea of a transaction: a group of changes that either all succeed or all fail. Consider moving money between two accounts in a hypothetical bank. Subtracting from one account and adding to the other must happen together. If the system crashed halfway, a transaction lets the database roll back to the state before it began, rather than leaving the books half updated.

Many relational systems describe this reliability with four properties, abbreviated ACID: atomicity (all or nothing), consistency (rules are respected), isolation (simultaneous changes do not interfere) and durability (committed changes survive a crash). The exact guarantees vary between products and settings, so it is worth reading what a particular system promises.

Where the data physically lives

A database stores its data on disk, often with copies held in memory for speed. It may run on one machine, or be spread across many servers. Many organizations now rent database services through cloud computing instead of running their own hardware, which shifts maintenance work to a provider but does not remove the need to plan for failure. Because a single failed disk can destroy years of records, regular data backups are part of running any database responsibly.

Not all data is shaped like a table

Rows and columns suit things like orders and accounts. Other material, such as emails, photos and recordings, does not fit neatly into columns. That difference is explored in the discussion of unstructured data, and it is one reason several different kinds of database exist.

Security and privacy

Databases often hold personal details, so access controls matter: who may read, change or delete which tables. When databases are exposed or poorly protected, the result can be data breaches. Organizations typically limit access, encrypt sensitive fields and keep records of who did what, though practices vary.

A mental model to keep

Think of a database as a well-run filing office. Each kind of document has its own cabinet (tables), every folder has a unique label (keys), a catalog tells you where to look (indexes), and strict procedures keep two clerks from damaging each other’s work (transactions). The details differ between systems, but that structure explains most of what you will meet when you read about data.