The Data Dilemma and Hackathon Schemas

In Part 1, we built the "actor" of our website—the frontend—using HTML, CSS, and JavaScript. It looks beautiful and has interactivity. But when a user types information into this beautiful website, where does it go?

We can't just expect the system to understand a standard Excel sheet because it isn't visual; it is based on code. We need a proper database.

During our session, Gagana, Chaitanya, and I broke down the two massive categories of databases that power the web: Relational and Non-Relational.

1. Relational Databases (SQL): The Physical World

When should you use a relational database? Whenever there is a concrete, physical relationship between two entities.

Imagine you have a student and a teacher. We can easily map the relationship between them. That student might be male or female, and in their first or second year. Automatically, when you map this out, you start creating columns, and every new student becomes a row of data.

This is what a relational database (like MySQL or PostgreSQL) does perfectly. It organizes data that exists with strict physical relationships in the real world.

2. Non-Relational Databases (NoSQL): The Flexible Alternative

But what if the data doesn't have a strict physical relationship?

Take a video game, for instance. There is no physical logic or physical relationship to tie the data elements together; it is just a concept we created. In these cases, a non-relational database (like MongoDB or Firebase) shines.

3. A Real-World Example: Building a Hackathon Database

To make this crystal clear, we looked at a real-world scenario from when we were managing data for the Git-A-Thon hackathon. I asked the group: Who are the actors (or models) in this database?

We quickly listed them out:

• Judges
• Problem statements
• Registrations and contact information
• Rounds of judging and score tables

In a perfect world with endless time, we might build a relational SQL database. One judge goes and scores many people, and that judge belongs to one college. You would write a strict schema and build custom APIs.

But in the fast-paced environment of a 24-hour hackathon, we faced severe time constraints, and the team wasn't fully equipped to write all those complex relationships from scratch.

Instead, we used a non-relational database. By using a platform like Firebase—which is a Software as a Service (SaaS)—all of that complex schema writing and API building gets abstracted into a single, simple function. It allowed us to ship a simplistic solution rapidly without worrying about rigid data tables.