What is SQL? A Vampiric Breakdown

sql
Written By Daniel Cohen

HemoGlobal, the Vampiric Conglomerate tasked with ensuring the harvest continues.

What is SQL?

A very basic introduction to SQL.

Table of Contents

  • Important Terminology

  • What is a Database?

  • What is SQL?

  • What is SQL used for?

  • A Supernatural spin

Important Terminology

  • SQL (Structured Query Language)

  • Database

  • Database table (An entity we try to model using data → e.g., car, animal)

  • Records (Rows / Single observations of data)

  • Fields (Columns / Single traits of the entire table)

  • SQL Keywords

    • SELECT

    • FROM

    • LIMIT

    • CREATE VIEW

    • DISTINCT

 

💡 Before we can understand what SQL is we must first understand what a database is, how they work, and why we use them.

 

What is a Database?

To not beat around the bush and answer the question directly, Databases are essentially secure storage spaces for data. We can put any type of data into a Database. Images, text, emails, whether that data is structured (in a table) or unstructured (chaos), the data can all be placed securely for quick retrieval, deletion and manipulation using Databases.

⚠️ There are many different kinds of databases and they each have their own ways of storing data. The two most ‘famous’ are SQL and NoSQL databases. Since SQL databases are almost synonymous with structured, tabular data, for the rest of this article I will be talking about structured data, SQL databases.

Databases store data separately in tables that may or may not be inter-related. For example, we may have a table named users , where each row (→ this way) would be a specific instance of a user and each field (↓ this way) would be a trait that a single user (row / record) may have.

 

Users Table

A screenshot of a markdown table. The users table.

  • As we can see from the Users Table above

    • The whole table is pertinent to a specific type of data → Users

    • Each row / record is a single instance where all the data relates to a single user

    • Each field / column is a single data point that is pertinent to the record it has data to.

Why we use Databases… or not?

We use Databases mostly because of their ability to be versatile while maintaining intense security. Prior to databases, we would use anything from txt files to CSVs to JSON, etc… Some teams might still be finding themselves using these insecure methods for any number of reasons from an inability to house a database or economic destitution. Perhaps even a non-understanding of databases could lead a team to be ill-equipped to use or set up a database for use. But ultimately, databases enhance many aspects of data storage and manipulation and should definitely be taken into consideration when planning any technical venture.

 

What is SQL?

SQL (pronounced sequel) stands for Structured Query Language and it’s called that because it uses a structured means of storing data that can be manipulated using queries (essentially written requests to the database to perform some action).

SQL stores data in neat tables where each row (aka, records → essentially a single observation of data pertinent to the table itself.) Each record will have data points for each table field. Like the example above.

Using SQL we can perform CRUD (Create, Read, Update, Delete) manipulations on data tables.

 

Basic SQL Commands

SELECT We use this to select data from a column or table. SELECT first_name FROM Indicates the table from which data should be retrieved FROM. FROM user AS Renames a column or table with an alias for readability. SELECT first_name AS fn CREATE VIEW Creates a virtual table based on a stored query result. LIMIT Restricts the number of records returns from a query. LIMIT 10; GROUPBY Aggregates (groups together) data across rows sharing a common field. COUNT() counts the number of rows matching a specified criteria. AVG() calculates the average of the field placed inside. → AVG(salary)

 

What can we do with SQL?

  • Select Data

SELECT email
FROM users;

  • Filter Data

SELECT email
FROM users
LIMIT 10;

  • Count Data

SELECT COUNT(email)
FROM users

  • Aggregate Data

SELECT department, COUNT(*) AS total_employees, AVG(salary) AS average_salary
FROM employees;

  • Sort / Group Data

SELECT department, AVG(salary) AS average_salary
FROM employees
GROUP BY department
ORDER BY average_salary DESC;
 

A Supernatural Spin

Imagine a world filled with supernatural creatures—vampires, werewolves, witches, and every nightmarish monster you’ve ever encountered in your head—all coexisting in secret. They hide behind the curtain and control every facet of our lives. What we eat. What clothes are available to buy. Whether we’ll suddenly change to paper bags or plastic bags, and even who the leaders of the world will be. Their goal? To feed on humanity without us knowing—to maintain control—, to survive. But, managing something like that, this hidden society, requires meticulous record-keeping. How do they maintain control?

Enter the structured power of SQL databases! The Vampiric Council—the conglomerate of all Vampire society, responsible for maintaining the Monster’s food supply of humans by perpetuating war and death. This aggregate, for example, uses SQL to track vital information such as bloodline lineage, individual crime records, political careers, and country tensions so that they can easily and with thorough information, pick the leaders of the world. With a single SELECT query, they can quickly determine the best human to take control of any particular region to perpetuate the war machine, which in turn, ensures the harvest continues for all monster-kind. SQL’s rigid structure ensures that every human being is accounted for and their futures already set in stone, making the chaos manageable and keeping ancient secrets safely secured within neatly organized tables.

Let's imagine how the vampires use these specific tools…

  • Assume the Council maintains a database table named Human_Asset.

  • This table includes columns like AssetID, FullName, CurrentRegion, PoliticalStanding, and crucially, a ConflictPotentialScore (perhaps 1-10, higher means more likely to incite war/unrest).

 

Example 1: Tallying Potential Instigators by Region

The Council needs a high-level overview of where their most promising (i.e., potentially destructive) human assets are located.

Goal: Count the number of tracked human assets in each CurrentRegion.

SQL in Action: 

SELECT
    CurrentRegion,
    COUNT(AssetID) AS NumberOfAssets
FROM
    Human_Asset
GROUP BY
    CurrentRegion;

Breakdown & Narrative Context:

  • SELECT CurrentRegion, COUNT(AssetID) AS NumberOfAssets: This command tells the database to list each region (CurrentRegion) and then count (COUNT(AssetID)) how many individuals (assets) are associated with that region. The AS NumberOfAssets simply renames the count column for clarity in the report – perhaps titled "Regional Asset Distribution" on some ancient vampire's screen.

  • FROM Human_Asset: Specifies that the information should be pulled from their main table thats tracking humans, Human_Asset.

  • GROUP BY CurrentRegion: This critical command groups all the rows by region before counting. Without it, COUNT would just give the total number of humans tracked across all regions. With GROUP BY, they get a specific count for each region.

Usefulness for the Vampiric Council: This query provides immediate insight into geopolitical distributions. A region showing a high NumberOfAssets might be flagged as a priority zone for initiating destabilization efforts, as they have many potential pawns already identified there. It helps them allocate their manipulative resources effectively to perpetuate the necessary chaos for the broader monster society's survival.

 

Example 2: Assessing Average Destructiveness by Region

Instead of finding the single most destructive person immediately, they can assess the average potential for conflict within each region. This tells them which regions are generally more 'volatile' based on the assets they track there.

Goal: Calculate the average ConflictPotentialScore for tracked humans, grouped by their CurrentRegion.

SQL in Action: (Using the singular table name Human_Asset as discussed)

SELECT
    CurrentRegion,
    AVG(ConflictPotentialScore) AS AveragePotential
FROM
    Human_Asset
GROUP BY
    CurrentRegion;

Breakdown & Narrative Context:

  • SELECT CurrentRegion, AVG(ConflictPotentialScore) AS AveragePotential: Selects the region and calculates the average (AVG()) of the ConflictPotentialScore for all assets within that region. AS AveragePotential gives this calculated average a clear name.

  • FROM Human_Asset: Specifies the source table.

  • GROUP BY CurrentRegion: Just like before, this groups the assets by region before calculating the average. This ensures they get a separate average for each unique region.

Usefulness for the Vampiric Council: This query gives the Council a strategic overview. A region with a high AveragePotential score (e.g., 8.5 out of 10) signals that the assets there are, on average, highly suited for fomenting (instigating or stirring up) conflict. They might prioritize manipulating leaders in that region, knowing the pool of candidates is generally more aligned with their destructive goals. It helps them identify the most fertile grounds for their war-machine strategy, even without pinpointing the single top individual initially.

Daniel Cohen
Next

The Differences Between Iterables