Non-Brand Data

Non-Brand Data

Home
Podcast
Chat
LinkedIn
👨‍💼Personalized Mentorship …
AI 🤖
Python 🐍
SQL crash course 🔢
RAG-To-Know🔍
Data Resource 🗂️
Like a Pro🏆
Data Career💼
About Non-Brand Data👇
Archive

Share this post

DataBites
DataBites
#14 Views
Copy link
Facebook
Email
Notes
More
SQL crash course 🔢

#14 Views

SQL Crash Course #14

Josep Ferrer's avatar
Cornellius Yudha Wijaya's avatar
Josep Ferrer
and
Cornellius Yudha Wijaya
Apr 25, 2025
9

Share this post

DataBites
DataBites
#14 Views
Copy link
Facebook
Email
Notes
More
2
Share
Cross-post from DataBites
Let's continue our SQL Learning together with Views! -
Cornellius Yudha Wijaya

All the course material is stored in the SQL Crash Course repository.

Hi everyone! Josep and Cornellius Yudha Wijaya from Non-Brand Data here 👋🏻

As promised, today we are publishing the next two issues of our SQL Crash Course – From Zero to Hero! 🚀

I am sure you are here to continue our SQL Crash Course Journey!📚

If this is your first time or you’ve forgotten what we’ll cover, we will examine seven key SQL topics, each divided into multiple posts across Non-Brand Data and DataBites.

📚 Previously in SQL Basics…

Remember last Thursday, we already saw:

📌 #11 – Subqueries
📌 #12 – CTEs

Today, we will continue our learning by exploring two new brand issues for the advanced SQL:

📌 #13 – Recursive:

Cornellius Yudha Wijaya
in
Non-Brand Data
explains what recursive queries are and how to implement them using SQL:

📌 #14 - Views: The issue you are reading right now where I will teach everything about saved SQL query that acts like a virtual table (Views).

So don’t miss out—let’s keep the SQL momentum going!

🧱 What are SQL Views?

A view is a virtual table based on a SQL query.

It behaves like a table — you can SELECT form it, join it with others, and filter it — but it doesn’t store data itself. Instead, it runs the underlying query each time you call it.

Think of it as a saved query that gives you a clean interface to complex logic.

Basic syntax:

CREATE VIEW view_name AS
SELECT 
   column1, 
   column2
FROM original_table
WHERE condition;

Want to inspect it?

SELECT * FROM view_name;

Want to update a view?

CREATE OR REPLACE VIEW view_name AS ...

✅ When to Use Views:

👉🏻 When you want to encapsulate business logic (e.g. revenue metrics)
👉🏻 When you want to simplify complex joins or calculations
👉🏻 When multiple users or tools need consistent query logic
👉🏻 When security matters — expose only selected columns

Let’s See Views in Action! 👇🏻

#1. Simplifying Repetitive Logic

🧩 Real-world scenario: “We often analyze posts from a specific newsletter – let’s create a shortcut.”

✅ Without a view:

SELECT *
FROM posts
WHERE newsletter_id = '1112A';

✅ With a view:

CREATE VIEW databites_posts AS
SELECT *
FROM posts
WHERE newsletter_id = '1112A';

-- Reuse easily:
SELECT * FROM databites_posts
WHERE published_at > '2024-02-01';

🧠 Why View: Centralizes the filtering logic, reducing repetition across multiple queries.

#2. Reusable Metrics

🧩 Real-world scenario: “We want a summary of post-level performance including points and interaction counts.”

CREATE VIEW post_performance AS
SELECT 
  p.id AS post_id,
  p.name,
  n.name AS newsletter_name,
  SUM(i.points) AS total_points,
  COUNT(i.id) AS interaction_count
FROM posts p
JOIN newsletters n ON p.newsletter_id = n.id
LEFT JOIN interactions i ON p.id = i.post_id
GROUP BY p.id, p.name, n.name;

-- Use it like this:
SELECT *
FROM post_performance
WHERE total_points > 5;

🧠 Why View: Clean, consistent KPIs across dashboards and teams.

#3. Hiding Sensitive Data

🧩 Real-world scenario: “Expose basic post engagement, but hide usernames or raw timestamps.”

CREATE VIEW public_post_insights AS
SELECT 
  p.id AS post_id,
  p.name AS post_title,
  COUNT(i.id) AS total_interactions,
  SUM(i.points) AS engagement_score
FROM posts p
LEFT JOIN interactions i ON p.id = i.post_id
GROUP BY p.id, p.name;

-- Simple and safe:
SELECT * FROM public_post_insights;

🧠 Why View: Useful for dashboards, stakeholder reporting, and access-controlled environments.


🎯 Summary: Why You Should Use Views

Views = Clean, Modular, and Safe SQL Interfaces.

🔹 Consistency: Define logic once, use it everywhere
🔹 Clarity: Hide complexity behind readable names
🔹 Control: Restrict columns exposed to users/tools
🔹 Convenience: Combine with tools like BI dashboards for speed


👉🏻 SQL playground with all views examples

How to Get Started 🚀

Over the coming weeks, we’ll guide you through:

✅ SQL Fundamentals
✅ Intermediate SQL
✅ Advanced SQL
✅ Database Operations
✅ Writing Efficient Queries

Once you grasp the basics, practice is key! Start working on real-world projects and solving hands-on data problems.

What’s Next? ➡️

This is the first of many posts about the upcoming SQL Courses. It will only explain what SQL is in its crude form.

To get the full experience and fully immersed in the learning:

👉 Subscribe to Databites.tech (By Josep)

👉 Subscribe to Non-Brand Data (By Cornellius)

👉 Check out the SQL Crash Course GitHub repo

👉 Share with your friend and whoever needs it!

🗓️ Every Thursday, you will have two new issues in your inbox!

Let’s dive in and make SQL less scary, more fun, and way more useful! 🚀

Josep & Cornellius

9

Share this post

DataBites
DataBites
#14 Views
Copy link
Facebook
Email
Notes
More
2
Share

No posts

© 2025 Cornellius Yudha Wijaya
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share

Copy link
Facebook
Email
Notes
More