What Is a Database?
Author: Domeny.ForSale editorial team Published
In brief: A database is an organised collection of information that can be searched, added to and updated. Online shops, banks and booking systems, among others, use databases to store information about customers, products or transactions. A database is usually managed by specialised software that also controls access permissions and ensures operations are carried out correctly.
A database and the software that manages it
A database can be compared to a well-organised filing system. Each piece of information has a defined place and format, so there is no need to look through the entire collection to find the entry you need. Unlike a paper filing system, a database also lets you quickly bring information together, for example to display all orders placed by a particular customer.
The database itself is not the same as a database management system, which is software used to store, retrieve and control data. PostgreSQL, MySQL and SQLite are examples of these systems. In everyday language, the term “database” often refers both to the collection of information and to the software that manages it, but technically these are two different components.
Someone using a shop or application usually does not work directly with the database. They fill in a form or press a button, and the application passes the appropriate command to the database management system.
How data is organised and retrieved
In a relational database, information is stored in tables that can be linked to one another. A row, also called a record, describes a single entity, such as a product. Columns specify its attributes, such as its name, price or the number of units available.
A simplified product table might look like this:
| Product ID | Name | Price | Units available |
|---|---|---|---|
| 101 | White mug | 29 zł | 18 |
| 102 | Navy blue mug | 32 zł | 7 |
A primary key is a field or set of fields that uniquely identifies a record. In this example, it is the product ID. Even if two products have the same name, their IDs allow them to be distinguished.
A separate table can contain orders, and another can contain the line items in those orders, with product IDs and the quantities ordered. These relationships reduce unnecessary duplication of information. This does not mean that copying data is forbidden, however: an order line item usually stores the price at the time of purchase, because later changes to the price list should not alter the sales history.
SQL, a command language for retrieving and modifying data, is often used to work with relational databases. A query might, for example, retrieve products with fewer than ten units left. Searches can be made faster by indexes — additional structures that work rather like the index in a book. However, they take up space and increase the cost of updating data, so they are not created without limits.
What happens in the database during a purchase
Imagine a shop with just one unit of a product left. Two people try to buy it almost simultaneously. Simply displaying the number “1” on the website is not enough: the system must determine which operation can succeed.
A transaction helps with this. It is a group of operations treated as a single unit. Creating an order and reducing the stock level can be carried out so that either both changes are committed or neither is saved. Properly designed handling of transactions and concurrent access helps prevent the same last unit from being sold to two people.
However, a database does not automatically ensure that the entire shop works correctly. The programmer must define the rules properly, such as prohibiting negative stock levels. Payment through an external system requires additional handling of errors and confirmations — it does not become part of a local transaction simply because it relates to the same purchase.
How a database differs from a spreadsheet
A spreadsheet works well for manually compiled lists, calculations and analysis. If one person maintains a small list of office equipment, a spreadsheet may be a simpler solution than a separate application with a database.
A database becomes particularly useful when:
- many people or programs change information at the same time;
- the data has numerous relationships, such as those between customers, contracts and payments;
- rules need to be enforced consistently, such as ensuring order numbers are unique;
- an application needs to retrieve and store data automatically and regularly.
The distinction does not depend solely on the number of rows. Even a small booking system may need a database because it must prevent the same time slot from being allocated to several people. On the other hand, a large one-off dataset may still be convenient to analyse in a spreadsheet.
How to choose a database type and look after your data
Not all databases use linked tables. NoSQL databases is a collective term for various solutions, including document databases, which store information as documents with a defined structure, and key–value databases, which assign a value to a unique key. They are not inherently faster or better than relational databases — the choice depends on how information is stored and retrieved.
For a typical application handling customers, orders and billing, a relational database is often a sensible starting point. If you are setting up an off-the-shelf content management system or shop, first check its vendor’s requirements. The software usually specifies which database systems and versions it supports.
Whatever the technology, restricted access permissions, updates and backups are necessary. A backup allows data to be recovered after a failure or mistake, but its usefulness should be checked by performing a test restore. Simply knowing that a backup “runs every day” does not confirm that it can be used to recover a working database.
Before choosing a tool, write down what information you want to store, who will change it and which errors the system should prevent. This short description will help you assess whether a spreadsheet or an off-the-shelf application is sufficient, or whether you need a custom solution with a database.
See also: What Is 2FA?
Read also
