In Part 1, I discussed database types and why QAs need to learn how to do the READ operations. Now let's dive into the actual SQL commands you'll use daily. [`User` Table] ────────────── ID │ Name │ Email ────────────── 1 │ john │ john@test.com 2 │ mary | mary@test.com 3 │ bob │ bob@test.com ────────────── ──────────────────────────────── ▶ 𝐐𝐮𝐞𝐫𝐲 #𝟏: 𝐁𝐚𝐬𝐢𝐜 `𝐒𝐄𝐋𝐄𝐂𝐓` - 𝐑𝐞𝐚𝐝 𝐀𝐥𝐥 𝐃𝐚𝐭𝐚 ······································································································································ SELECT * FROM Users; ······································································································································ What it does: Returns ALL columns and ALL rows from the Users table. QA Example: After registering multiple users, you want to see all newly created accounts in the database. ──────────────────────────────── ▶ 𝐐𝐮𝐞𝐫𝐲 #𝟐: `𝐒𝐄𝐋𝐄𝐂𝐓 𝐖𝐢𝐭𝐡 𝐖𝐇𝐄𝐑𝐄` - 𝐅𝐢𝐥𝐭𝐞𝐫𝐞𝐝 𝐑𝐞𝐚𝐝 ····································································································································· SELECT * FROM Users WHERE Email = 'bob@test.com'; ······································································································································ What it does: Returns all data in the row for the user with that specific email address: ────────────── 𝟑 │ 𝐛𝐨𝐛 │ 𝐛𝐨𝐛@𝐭𝐞𝐬𝐭.𝐜𝐨𝐦 ────────────── QA Example: Test user registration and verify that exact account was created with correct details. ──────────────────────────────── 𝐓𝐢𝐩𝐬: ⟡ Start with `𝐒𝐄𝐋𝐄𝐂𝐓 *` to see all data, then add `𝐖𝐇𝐄𝐑𝐄` to narrow it down ⟡ Always test your queries on a test database first, never production 𝐏.𝐒. 🚩 𝐈𝐟 𝐲𝐨𝐮 𝐡𝐚𝐯𝐞𝐧’𝐭 𝐰𝐚𝐭𝐜𝐡𝐞𝐝 𝐢𝐭 𝐲𝐞𝐭, 𝐲𝐨𝐮𝐫 𝐧𝐞𝐱𝐭 𝐬𝐭𝐞𝐩 𝐢𝐬 𝐭𝐡𝐞 𝐅𝐑𝐄𝐄 𝟑-𝐩𝐚𝐫𝐭 “𝐌𝐚𝐧𝐮𝐚𝐥 𝐐𝐀 → 𝐒𝐃𝐄𝐓” 𝐰𝐨𝐫𝐤𝐬𝐡𝐨𝐩, 𝐚 𝐬𝐡𝐨𝐫𝐭 𝐦𝐢𝐧𝐢-𝐜𝐨𝐮𝐫𝐬𝐞 𝐭𝐡𝐚𝐭 𝐠𝐢𝐯𝐞𝐬 𝐲𝐨𝐮 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐫𝐨𝐚𝐝𝐦𝐚𝐩 𝐭𝐨 𝐛𝐞𝐜𝐨𝐦𝐢𝐧𝐠 𝐚 𝐦𝐢𝐝-𝐥𝐞𝐯𝐞𝐥 𝐒𝐃𝐄𝐓 𝐚𝐧𝐝 𝐩𝐚𝐬𝐬𝐢𝐧𝐠 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬.

I received several DMs asking the same question: "Should I learn SQL or NoSQL first?" Here's the straightforward answer... ──────────────────────────────── As a beginner who is learning Databases, SQL databases are your best bet. Here's why: ➤ SQL has universal standards that work across different databases (MySQL, PostgreSQL, SQL Server, etc.) ➤ SQL databases are extremely popular. The chances of using SQL at work are incredibly high Simply put: learn SQL first, and you'll be prepared for most real-world job scenarios. ──────────────────────────────── In case you did not know the difference: 𝐒𝐐𝐋 𝐯𝐬 𝐍𝐨𝐒𝐐𝐋: 𝐓𝐡𝐞 𝐓𝐰𝐨 𝐌𝐚𝐣𝐨𝐫 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐓𝐲𝐩𝐞𝐬 Think of databases as organized storage systems for data. There are two main types: 𝐒𝐐𝐋 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 - This is essentially a super-powered Excel spreadsheet that stores data in tables with rows and columns. Each piece of information has its specific type (number, text, etc) and place. Everything follows a strict structure. 𝐍𝐨𝐒𝐐𝐋 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 - Think of this as storage for JSON-like files. Data is stored like individual files or nested folders where each entry can have different fields and structures. One user might have 5 pieces of information, another might have 10. Both work fine. It's flexible and doesn't force everything into the same format. ──────────────────────────────── Another important focus is: start with learning READ operations In most testing scenarios, whether manual or automated tests interact with an application through its interface, you need to verify that the 𝐜𝐨𝐫𝐫𝐞𝐜𝐭 𝐝𝐚𝐭𝐚 𝐰𝐚𝐬 𝐬𝐚𝐯𝐞𝐝 𝐢𝐧 𝐭𝐡𝐞 𝐛𝐚𝐜𝐤𝐞𝐧𝐝. For example: ➤ User registers on a website → You check the database to confirm their account was created ➤ User updates their profile → You verify the changes were stored correctly ➤ User deletes an item → You confirm it's actually removed from the database SQL READ operations allows you to peek behind the scenes and validate what really happened in the system. 𝐏.𝐒. 🚩 𝐈𝐟 𝐲𝐨𝐮 𝐡𝐚𝐯𝐞𝐧’𝐭 𝐰𝐚𝐭𝐜𝐡𝐞𝐝 𝐢𝐭 𝐲𝐞𝐭, 𝐲𝐨𝐮𝐫 𝐧𝐞𝐱𝐭 𝐬𝐭𝐞𝐩 𝐢𝐬 𝐭𝐡𝐞 𝐅𝐑𝐄𝐄 𝟑-𝐩𝐚𝐫𝐭 “𝐌𝐚𝐧𝐮𝐚𝐥 𝐐𝐀 → 𝐒𝐃𝐄𝐓” 𝐰𝐨𝐫𝐤𝐬𝐡𝐨𝐩, 𝐚 𝐬𝐡𝐨𝐫𝐭 𝐦𝐢𝐧𝐢-𝐜𝐨𝐮𝐫𝐬𝐞 𝐭𝐡𝐚𝐭 𝐠𝐢𝐯𝐞𝐬 𝐲𝐨𝐮 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐫𝐨𝐚𝐝𝐦𝐚𝐩 𝐭𝐨 𝐛𝐞𝐜𝐨𝐦𝐢𝐧𝐠 𝐚 𝐦𝐢𝐝-𝐥𝐞𝐯𝐞𝐥 𝐒𝐃𝐄𝐓 𝐚𝐧𝐝 𝐩𝐚𝐬𝐬𝐢𝐧𝐠 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬.