Theory
When rows and columns fight your data
In BCA205 and BCA303 you stored data in TABLES: fixed columns, every row the same shape, related tables joined together. It is powerful and precise.
But FestConnect's events are awkward in a table: a cultural event has a dress code, a coding contest has a programming-language list, a workshop has a materials list. Different events, different fields. Forcing them into one rigid table means dozens of mostly-empty columns.
This is where NoSQL databases shine: they store flexible, self-describing documents instead of rigid rows. This unit rebuilds FestConnect's data on MongoDB, and it starts with WHY NoSQL exists.
Theory
NoSQL, formally
NoSQL (often read as 'Not Only SQL' or 'non-relational') databases store data WITHOUT the fixed table-row-column schema of relational databases.
There are 4 main types:
- Document (MongoDB): data as JSON-like documents: this unit's focus
- Key-value (Redis): simple key to value pairs
- Column-family (Cassandra): rows with flexible columns
- Graph (Neo4j): nodes and relationships
The unifying idea: drop the rigid schema. Where a relational database demands every event fit ONE table shape, a document database lets each event be its own flexible document with whatever fields it needs.
At a glance
Relational (SQL) vs NoSQL
| Aspect | Relational (SQL) | NoSQL |
|---|---|---|
| Structure | Fixed tables, rows, columns | Flexible: documents, key-values, etc. |
| Schema | Strict, defined up front | Flexible or schema-less |
| Relationships | JOINs across tables | Often embedded/denormalised, no joins |
| Scaling | Usually vertical (bigger server) | Horizontal (scale out across servers) |
| Best for | Complex transactions, strict consistency | Large-scale, changing, unstructured data |
Theory
Advantages and features
Why teams reach for NoSQL:
- flexible schema: fields can vary per record, so the data model evolves without painful migrations
- horizontal scalability: scale OUT by adding servers, handling very large data and traffic
- high performance for many read/write-heavy workloads
- handles unstructured/semi-structured data naturally
- developer-friendly: documents map cleanly to program objects (a MongoDB document looks like a JavaScript object)
One honest trade-off worth naming: many NoSQL systems relax strict consistency (the ACID guarantees relational databases prize) in favour of availability and scale. So NoSQL is not universally 'better': it is a different set of trade-offs, and relational databases remain the right choice for complex transactions and strict consistency.
Quiz
Which is a defining characteristic of NoSQL databases compared with relational ones?
- They always store data in fixed tables with strict schemas
- They use flexible, non-tabular structures (like documents) often without a rigid schema or joins
- They cannot store any structured data at all
- They are always faster than relational databases in every situation
Show the answer
They use flexible, non-tabular structures (like documents) often without a rigid schema or joins
NoSQL's defining trait is flexible, NON-tabular storage (documents, key-values, columns, graphs) usually without a rigid predefined schema and often without joins: the opposite of the fixed tables option A describes (that is relational). Option C overstates it: NoSQL handles structured and semi-structured data well; it just does not FORCE one rigid shape. Option D is the 'NoSQL is always better' myth this lesson refutes: NoSQL wins for scale and flexibility but trades away some consistency guarantees, and relational databases are still better for complex transactions. The honest framing: different trade-offs, not universal superiority.
Think first
Why FestConnect's events suit documents
FestConnect has cultural events, coding contests, and workshops, each with different extra fields. Explain why a document database handles this better than one rigid table. Then tap.
Show the answer
In a RELATIONAL table, every event must share ONE column set, so you either create a giant table with a column for every possible field (dress code, language list, materials...), most of which are empty for any given event, or you split into many joined tables: both clumsy. In a DOCUMENT database, each event is its OWN document with exactly the fields it needs: the Garba document has a dressCode field, the coding-contest document has a languages array, the workshop document has a materials list, and none carries the others' empty fields. The flexible schema fits naturally-varying data. That said, if the data were highly uniform and transaction-heavy (like bank accounts), a relational table would be the better tool. Match the database to the data's shape.
Watch out
NoSQL misconceptions
'NoSQL means no SQL-like queries': many NoSQL systems have rich query languages; the name means non-relational, not query-less.
'NoSQL is always better/faster': it trades consistency for scale/flexibility; relational is better for complex transactions.
'Schema-less means no structure': documents still have structure; it is just flexible, not enforced up front.
Forgetting the trade-off: relaxed consistency (eventual consistency) is a real cost in many NoSQL systems; know your consistency needs.
Theory
From concept to MongoDB
You now understand WHY NoSQL exists: flexible, scalable storage for data that resists rigid tables. The rest of Unit 1 gets concrete with the most popular document database, MongoDB: its data types and how to create and drop databases and collections, then full CRUD (create, read, update, delete) and the query, projection and aggregation operators. FestConnect's events are about to become MongoDB documents. Then React and Angular build the modern UI on top.
Summary
Key takeaways
- NoSQL databases store data in flexible, non-tabular structures instead of the rigid tables of relational databases.
- Four main types: document (MongoDB), key-value, column-family, graph.
- Versus relational: flexible/schema-less vs strict schema; embedded data vs joins; horizontal vs vertical scaling.
- Advantages: flexible schema, horizontal scalability, high performance, handles unstructured data, maps to objects.
- Trade-off: many NoSQL systems relax strict consistency (ACID) for availability and scale.
- NoSQL is not universally better: relational is still best for complex transactions and strict consistency.
- Memory hook: NoSQL drops the rigid table for flexible documents, trading strict consistency for scale.