Web_Dev_Grad

Relational databases, also known as SQL databases, are the most commonly used type of database in traditional applications. They use a structured, table-based approach to store data.

They use SQL, which is the standard language used to interact with relational databases. It is used for CRUD activities.

In relational databases, data is organized into separate tables, where each table represents a type of entity (e.g. Users, Orders, Products). Each contains a primary key (PK), which is a unique identifier for each record in a table (e.g., user_id or countryID). Relationships between tables are defined by foreign keys (FK), which act as a reference to a primary key in another table. For example an Orders table might include a user_id FK pointing to the Users table.

Relational databases are allow you to define clear and enforceable connections between different sets of data. For example, you can link a user to their orders or a product to its category. Using constraints and relationships like this ensures that data remains consistent and avoids duplication or orphaned records. SQL databases like PostgreSQL, MySQL, and SQLite have been around for decades, with robust tooling and strong community support. However they have a rigid schema defined in advance so changing this later can be complex and risky. As your application grows, managing deeply nested relationships or multiple joins can become difficult and performance-intensive and if your data is unpredictable or frequently changing, a relational model may slow you down.

Non-relational databases, commonly referred to as NoSQL databases, were developed to address the limitations of relational databases in handling large-scale, unstructured, or rapidly evolving data.

They are document oriented; storing data in documents, usually in formats like JSON, BSON, or XML (e.g., MongoDB). They can be:

• Graph Stores: Designed to handle networks of data and relationships (e.g., Neo4j).
• Key/Value Stores: Each item is stored as a key with an associated value (e.g., Redis).
• Time-Series Databases: Optimized for data that is indexed by time (e.g., InfluxDB).
• Wide-Column Stores: Uses tables, rows, and dynamic columns (e.g., Cassandra).
• Geospatial Databases: Optimized for storing and querying geographic data.

Collections (in MongoDB) are the equivalent of a table in a relational database. Each document is a standalone data record, roughly equivalent to a row, but more flexible. Fields in each document represent data, equivalent to columns in SQL. Every document also has a unique identifier (often an _id field in MongoDB) to allow quick access. But each document can have a different structure, making it ideal for projects where the data shape varies frequently.

Non-Relational Databases can be flexible, you can store documents with different fields and data types in the same collection. There's no need to pre-define a strict schema. This allows for faster development which is useful for fast-moving projects, prototyping, or applications with evolving data models. As such they are also scalable. Many NoSQL databases are built with horizontal scaling in mind, allowing data to be distributed across multiple machines easily.

However, Non-Relational Databases lack standardized relationships as there are no built-in foreign keys. Relationships must be handled manually through embedding (nesting documents within each other) or linking (storing references), in simple terms it is like making a lot of hyperlinked documents. This can lead to repeated data, which can create inconsistencies unless carefully managed. Because there are fewer enforced rules, it's easier to introduce errors or inconsistencies in your data structure.

Relational Database	MongoDB / Document DB
Table	Collection
Row	Document
Column	Field
Relationships	Linking / Embedding Docs