LearnByte's blog

Meet Rahul, a data engineer at an e-learning platform. Every night, he receives a spreadsheet from the marketing team with updates to customer data—some are new signups, some are updates to old customers, and a few need to be removed.

His challenge?

“How do I keep the master Customers table in the database in sync with this daily file—without running three separate queries?”

Chapter 1: The Old Way – Multiple Queries

Rahul used to write:

1. UPDATE existing records
2. INSERT new ones
3. DELETE obsolete ones

Each with its own logic and filters.

It worked, but was messy and error-prone.

Chapter 2: The Discovery – Enter MERGE

One day, his senior Dev said:

“Why not use the MERGE command?

It lets you update, insert, or delete in one go, based on matching conditions.”

Rahul tried it.

And it worked like magic.

Chapter 3: What MERGE Does (In Simple Words)

MERGE is like a smart negotiator between two tables (or datasets):

• The target: where you want to apply changes (e.g., Customers)
• The source: the incoming changes (e.g., UpdatedCustomerList)

It checks each row in the source and decides:

• If it matches a record in the target → UPDATE it
• If it doesn’t match → INSERT it as new
• If something in the target is missing from the source → optionally DELETE it

Chapter 4: Rahul’s New SQL Superpower

MERGE INTO Customers AS Target
USING UpdatedCustomerList AS Source
ON Target.CustomerID = Source.CustomerID

WHEN MATCHED THEN 
    UPDATE SET Target.Email = Source.Email, Target.Name = Source.Name

WHEN NOT MATCHED BY TARGET THEN 
    INSERT (CustomerID, Name, Email)
    VALUES (Source.CustomerID, Source.Name, Source.Email)

WHEN NOT MATCHED BY SOURCE THEN 
    DELETE;

In one clean command, Rahul could sync the tables.

Chapter 5: Why It Matters

• Faster development: fewer lines, less maintenance
• Cleaner logic: easier to understand and review
• Data consistency: fewer mistakes across INSERTs/UPDATEs
• Real-world need: syncing CRM systems, inventory lists, or user accounts

Conclusion:

Rahul no longer dreads the daily data sync.

He tells his team:

“MERGE is like hiring a smart assistant that looks at both lists and says,

‘I’ll update this, add that, and remove the rest—don’t worry.’”

Meet Zoya, a data coordinator at a large company. She uses SQL to run reports like:

“Show me all employees in the Sales department.”

Simple stuff.

One day, her manager asks:

“Can you also check if they’re active, group them by role, and skip the interns… unless it’s Monday?”

Zoya blinks.

“Wait, that’s not a simple SELECT anymore.”

That’s when her teammate Aamir smiles and says:

“You need T-SQL. Think of it as SQL with brains.”

Chapter 1: What is T-SQL, Really?

Aamir explains:

“SQL is like asking a question: ‘Show me all the customers.’

But T-SQL lets you think, decide, and respond.”

With T-SQL, Zoya could:

• Use variables to store conditions
• Use IF…ELSE to handle exceptions
• Loop through data with WHILE
• Add error handling like in real programming
• Create stored procedures for tasks she runs every day

Chapter 2: A Day with Plain SQL vs T-SQL

Plain SQL:

SELECT * FROM Employees WHERE Department = 'Sales';

That works fine…

But what if she needs this logic:

“If it’s Monday, include interns.

If not, exclude them. Also, count only active employees.”

Here’s how T-SQL helps:

DECLARE @Day VARCHAR(10) = DATENAME(WEEKDAY, GETDATE());

IF @Day = 'Monday'
    SELECT * FROM Employees WHERE IsActive = 1;
ELSE
    SELECT * FROM Employees WHERE IsActive = 1 AND Role != 'Intern';

“Whoa. SQL can now think like I do!” Zoya says.

Chapter 3: Automating the Routine

Before T-SQL, Zoya used to:

• Copy-paste queries
• Manually change filters every day
• Run the same logic over and over

Now, she writes a stored procedure:

CREATE PROCEDURE GetDailyEmployeesReport
AS
BEGIN
    -- Logic using T-SQL
END;

She just runs:

EXEC GetDailyEmployeesReport;

Done. Automated. Clean.

⸻

Chapter 4: Zoya’s Realization

T-SQL is not a different language.

It’s SQL + intelligence for Microsoft SQL Server.

“It’s like having a smart assistant who remembers things, makes decisions, and helps me do more than just ask questions.”

⸻

Conclusion: SQL Asks. T-SQL Thinks.

Zoya still writes SQL. But now she builds logic, handles exceptions, and automates tasks—all thanks to T-SQL.

“With T-SQL, I don’t just query data—I manage it like a pro.”

In the busy office of DataWorks Ltd., a helpful employee named Sita managed the company’s birthday email list.

Each morning, she had a list of 500 employee names and birthdates.

Her job?

“Check if today is their birthday, and if so, send them a greeting.”

She could:

• Go through each person, one by one
• Or use a smart way to check them all together

Her IT team showed her how this works in SQL.

Chapter 1: The WHILE Loop – Like a Checklist

Imagine Sita writing this on paper:

“Start at the top of the list.

While there are more names to check:

• Look at birthday
• If today, send email
• Move to next person.”

This is a WHILE loop in SQL:

DECLARE @counter INT = 1;
WHILE @counter <= 500
BEGIN
   -- Check birthday at row @counter
   SET @counter = @counter + 1;
END

It’s like a loop that says: “Keep doing this until you’re done.”

Chapter 2: The CURSOR – Like a Name-by-Name Whisper

Then her team said:

“What if you want to do something special with each row—like send a personalized message or record each action?”

That’s where CURSOR comes in.

It acts like a finger pointing at each row, one at a time.

DECLARE birthday_cursor CURSOR FOR
SELECT Name, Email, BirthDate FROM Employees;

OPEN birthday_cursor;
FETCH NEXT FROM birthday_cursor INTO @Name, @Email, @BirthDate;

WHILE @@FETCH_STATUS = 0
BEGIN
   IF CAST(@BirthDate AS DATE) = CAST(GETDATE() AS DATE)
      EXEC SendBirthdayEmail @Name, @Email;

   FETCH NEXT FROM birthday_cursor INTO @Name, @Email, @BirthDate;
END

CLOSE birthday_cursor;
DEALLOCATE birthday_cursor;

Sita’s Takeaway

• WHILE is like checking tasks on a numbered list.
• CURSOR is like moving through a table one row at a time, doing something custom for each.

Why This Matters

1. Batch operations are great—but row-by-row control is sometimes necessary.
2. CURSORs can handle row-specific logic when SQL alone can’t.
3. WHILE loops are great for repeating logic until a condition is met.
4. Use both wisely—they can be slower than regular SQL if used with big data.

Conclusion:

Sita now uses SQL’s WHILE loops for checking scheduled tasks

and CURSORs for crafting personal messages, one person at a time.

“Sometimes data needs a bulk push.

Sometimes, it needs a gentle, thoughtful walk—row by row.”

That’s what WHILE and CURSOR help you do.

Meet Arjun, a data analyst at a retail company called SmartKart. His job is to provide sales insights to different teams: marketing, finance, and customer support.

One day, his manager asks:

“Can you label each customer order as High, Medium, or Low value based on the amount spent?”

Arjun thinks:

“That’s not a column in the database… but I can create it using logic!”

That’s when he meets the two decision-makers in SQL:

• CASE
• IF

Chapter 1: The Power of CASE – Like a Switchboard

Arjun writes:

SELECT OrderID, CustomerName, TotalAmount,
  CASE
    WHEN TotalAmount >= 1000 THEN 'High'
    WHEN TotalAmount >= 500 THEN 'Medium'
    ELSE 'Low'
  END AS OrderValueCategory
FROM Orders;

Suddenly, every order in the report is labeled smartly.

“CASE is like asking SQL to make decisions row by row, just like if/else in normal language,” Arjun realizes.

Chapter 2: IF for Logic Outside Queries

Later, Arjun builds a stored procedure to email daily summaries. But he only wants to run it if today is a weekday.

He uses:

IF DATENAME(WEEKDAY, GETDATE()) NOT IN ('Saturday', 'Sunday')
BEGIN
  EXEC SendDailySummary;
END

This IF runs outside the query, controlling program logic (procedures, execution flow).

“So CASE works inside queries, IF works in procedures,” he tells his teammate.

Chapter 3: Best Use Cases

CASE is Best For:

• Categorizing values (e.g., Low/Medium/High orders)
• Conditional formatting in reports
• Handling NULLs or unexpected values
• Replacing complex nested IFs in SELECTs

IF is Best For:

• Conditional logic in stored procedures
• Deciding whether to run a command or not
• Executing different blocks of SQL depending on business rules

Chapter 4: Arjun’s Favorite Report

His marketing team asks:

“Can you show us each customer’s total spend and if they qualify for loyalty status?”

He delivers:

SELECT CustomerName, SUM(TotalAmount) AS TotalSpent,
  CASE
    WHEN SUM(TotalAmount) >= 5000 THEN 'Gold'
    WHEN SUM(TotalAmount) >= 2000 THEN 'Silver'
    ELSE 'Bronze'
  END AS LoyaltyStatus
FROM Orders
GROUP BY CustomerName;

Now they can launch targeted campaigns—all thanks to one CASE statement.

Conclusion: CASE and IF Are the Brains of Your Query

They don’t store data.

They add meaning to it.

They make your queries smarter.

Just like Arjun, you can use CASE to reshape raw numbers into stories, and IF to automate smart decisions behind the scenes.