Traditionally, relational databases (like SQL server, Oracle, and others) store the data in columns and rows format. This combination allows us to have a table, where each row is a total unit of information and each column represents the attribute (record) saved. Here is an example:
ClientID | FirstName | LastName | Phone | Address | DateOfBirth | RegistrationDate | |
1 | John | Doe | john@example.com | (555)555-1234 | 123 Main St | 5/15/1980 | 12/15/2022 |
2 | Jane | Smith | jane@example.com | (555)555-1235 | 321 Elm St | 3/13/1988 | 10/16/2021 |
3 | David | Johnson | david@example.com | (555)555-1236 | 345 Oak Rd | 12/12/1990 | 5/18/2022 |
4 | Sarah | Williams | sarah@example.com | (555)555-1237 | 22 Pine Ave | 11/14/1987 | 1/14/2023 |
5 | Michel | Anderson | michel@example.com | (555)555-1238 | 10 Cedar Ln | 7/30/1991 | 9/19/2022 |
Table: Client
– ClientID: is a unique identifier for each client and serves as the primary key for the table. |
– FirstName and LastName: store the first and last names of each client. |
– Email: stores the client’s email address. |
– Phone: stores the client’s phone number. |
– Address: stores the client’s physical address. |
– DateOfBirth: stores the client’s date of birth. |
– RegistrationDate: stores the date when the client registered with the system.
On the other hand, Key Value Stores save each unit of information as a separate and independent document. This approach allows us to have individual attributes per document, in the following example, we can understand how it works.
In this schema, we can add/modify/delete any attribute without affecting any other documents.