Most websites and applications use databases to store information. For example, the TesterToday website stores information about a user’s level in a database.
Depending on application requirements, the choice of a specific database implementation may vary. In some cases, an application can use a simpler approach, such as storing data in files.
Database is a storage system that allows us to efficiently store, process, and manage large volumes of information.
When we send a request from a browser, a mobile application, or a console, it is received by the backend server. The server processes the request and, if necessary, accesses the database, then returns a response to the client. In more complex systems, this chain may include multiple services interacting with each other.
Database entity is a specific object about which information is stored.
Any object has certain properties; for example, a “Candy” has a Name, Taste, and Filling.
A candy also has a unique identifier so that each candy can be distinguished precisely. Constraints may be applied to candy properties; for example, the candy identifier is a number, and a string cannot be stored there.
| Identifier | Name | Taste | Filling |
|---|---|---|---|
| 1 | Cosmic Freshness | Mint | No |
| 2 | Minty Nebula | Citrus-mint with a light tang | Yes |
In turn, the database schema is a logical representation of the database structure. Data can be stored in different forms. Let’s look at two popular data storage models.
Data is stored in tables consisting of rows and columns.
Database schema:
Example:
Table cat
| id | name | age |
|---|---|---|
| 1 | Cat Astronaut | 4 |
Table candy
| id | name | taste | filling | cat_id |
|---|---|---|---|---|
| 3 | Cosmic Freshness | Mint | true | 1 |
Tables cat and candy are linked using the cat identifier cat_id specified in the table candy.
A relationship can be one of three types:
Between the tables candy and cat a one-to-many relationship is established. Each candy belonging to the Cat Astronaut has a field cat_id that contains its identifier.
Databases with this structure are called relational.
Data is stored as collections of documents, usually in JSON format.
The database schema is absent.
If candies are needed independently of the owning cat, we would prefer to store them in a separate collection, referencing specific candies in the cat document by their identifiers.
Document cat
{
"_id": {},
"name": "Cat Astronaut",
"age": 4,
"candies": [
{
"$oid": "647747066566feb9b8618b5c"
}
]
}Document candy
{
"_id": {
"$oid": "647747066566feb9b8618b5c"
},
"name": "Cosmic Freshness",
"taste": "Mint",
"filling": true
}If we are only interested in a cat together with the candies it owns, we can store its candies in an embedded form directly inside the cat document.
{
"_id": {},
"name": "Cat Astronaut",
"age": 4,
"candy": [
{
"name": "Cosmic Freshness",
"taste": "Mint",
"filling": true
}
]
}Document-oriented databases are considered more flexible because they impose fewer constraints on data structure. Entity properties in a document-oriented database are not rigidly defined and, unlike columns in a relational database, may vary from document to document.
Уровень повышен!
