Day 31 of #100DaysOfCode — SQL + NoSQL Basics

Source: Dev.to

Structured Way (Tables and Rows)

It is what is called a Relational Database — a way of organizing data into tables, where:

• Table → represents one entity (e.g., Users, Orders)
• Row → one record/entry in that table (e.g., one user)
• Column → an attribute/field (e.g., name, email, age)
• Cell → the actual value where a row and column intersect

It looks exactly like a spreadsheet:

🔑 Key Concepts

• Schema – the overall structure/blueprint of all your tables
• Primary Key – a unique identifier for each row
• Foreign Key – a column that links one table to another
• Relationship – how tables are connected

🟦 SQL Basic Syntax

Create a table

CREATE TABLE users (
  id    INT PRIMARY KEY AUTO_INCREMENT,
  name  VARCHAR(100) NOT NULL,
  email VARCHAR(255) UNIQUE,
  age   INT
);

Insert rows

INSERT INTO users (name, email, age)
VALUES ('Alice', 'alice@email.com', 28);

Read data

SELECT name, email
FROM users
WHERE age > 25
ORDER BY name ASC
LIMIT 10;

Update a row

UPDATE users
SET age = 29
WHERE email = 'alice@email.com';

Delete a row

DELETE FROM users
WHERE age `, `<`, `IN`, `LIKE`.*

Update a document

db.users.updateOne(
  { email: "alice@email.com" },
  { $set: { age: 29 } }
);

Delete documents

db.users.deleteMany({ age: { $lt: 18 } });

Join collections (aggregation with $lookup)

db.orders.aggregate([
  {
    $lookup: {
      from: "users",
      localField: "user_id",
      foreignField: "_id",
      as: "user"
    }
  },
  { $unwind: "$user" }
]);

Aggregation pipeline example

db.users.aggregate([
  { $match: { age: { $gt: 20 } } },
  { $group: { _id: "$age", count: { $sum: 1 } } },
  { $sort: { count: -1 } }
]);

🔵 Use Cases for NoSQL / Document Databases

Document databases and NoSQL excel wherever data is fluid, scale is massive, speed is critical, or the structure of each record genuinely varies. Typical real‑world scenarios include:

• Content Management & Blogging Platforms
• Social Media Feeds & User Profiles
• Real‑time Chat & Messaging
• Product Catalogs
• Mobile & Gaming Apps
• User Activity & Behavioral Analytics
• IoT & Sensor Data
• Recommendation Engines
• Logistics & Delivery Tracking
• Rapid Prototyping & Startups

🔵 SQL vs 🟠 NoSQL: When to Use Which?

Why SQL Wins

Why NoSQL Wins

Both paradigms have their strengths; the right choice depends on the specific requirements of your application.

Financial/Transactional Systems

Banks, ERP, e‑commerce backends

When to Use NoSQL

🧭 Quick Decision Guide

Is the data relational with a stable schema?      → SQL
Need ACID compliance (finance, healthcare)?       → SQL
Unknown/flexible data structure?                  → NoSQL (Document)
Massive scale, simple lookups?                    → NoSQL (Key‑Value)
Graph relationships (social networks)?            → NoSQL (Graph)
Time‑series or IoT data?                          → NoSQL (Wide‑Column)

✅ Conclusion

Day 31 gave me a clear picture of how SQL and NoSQL differ—not just syntactically, but philosophically.

• SQL focuses on structure, rules, and consistency.
• NoSQL prioritizes flexibility, speed, and scalability.

Understanding when to choose each one is a core skill for backend developers, and this comparison helped solidify that understanding.

Tomorrow I’ll build on this foundation as I continue my #100DaysOfCode journey.

Thanks for reading. Feel free to share your thoughts!