Note: In MongoDB, it’s customary to name fields and collections using a camelCase notation, with no spaces between words, the first word written entirely in lowercase, and any additional words having their first letters capitalized. Let’s imagine the contact card must store information about social media accounts the employee uses and add them as nested objects to the document: Documents can be also nested - meaning that a field within one document can have a value consisting of another document - making it possible to store complex data within a single document entry. Fields can differ between different documents in the same database, and you can modify the document’s structure at will, adding or removing fields as you go. In document databases, documents are not only self-describing but also their schema is dynamic, which means that you don’t have to define it before you start saving data. This is not the case with document databases, which offer you the freedom to save multiple documents with different schemas together with no changes to the database itself. You would have to adapt the database schema both to allow storing multiple departments as well as middle names, and you would have to provide a middle name for Sammy or else fill the column for that row with a NULL value. In a relational database, you’d be unable to store both of these example contact cards in the same table, as they differ in structure. In the case of documents, their schemas are reflected in their field names and what kinds of values those fields represent. A database’s schema is its formal structure, which outlines what kind of data it can hold. Also, this document’s department field stores not a single value, but an array of two values: "Finance" and "Accounting".īecause these documents hold different fields of data, they can be said to have different schemas. For instance, it adds a new field called middleName. This second document has a few differences from the first example. This sample document represents a company contact card, describing an employee called Sammy: The following is an example of a document that might appear in a document database like MongoDB. You might think of a document as a self-contained data entry containing everything needed to understand its meaning, similar to documents used in the real world. What is a Document Database?īreaking free from thinking about databases as consisting of rows and columns, as is the case in a table within a relational database, document databases store data as documents. Examples used in this article reference MongoDB, a widely-used document-oriented database, but most of the concepts highlighted here are applicable for most other document databases as well. This conceptual article outlines the key concepts related to document databases as well as the benefits of using them. These features make NoSQL databases useful for handling large volumes of data and fast-paced, agile development. NoSQL databases offer a high level of scalability as well as flexibility in terms of data structure. These new database models are jointly referred to as NoSQL databases, as they usually do not use Structured Query Language - also known as SQL - which relational databases typically employ to manage and query data. To break free from the rigid structure imposed by the relational model, though, a number of different database types have emerged in recent years. For many years the database landscape was dominated by relational databases, which organize data in tables made up of rows. More and more commonly, websites and applications involve collecting, storing, and retrieving data from a database. IntroductionĪlthough they were first invented decades ago, computer-based databases have become ubiquitous on today’s internet. The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |