A multi-index Student Records Management System built in Java, implementing multiple data structures to enable fast lookups across different attributes simultaneously.
This project implements a Student Records Management System in Java that stores and retrieves student data using multiple data structures in parallel. The key design challenge is that the same student record must be efficiently searchable by student ID, by name, and by GPA — each requiring a different underlying structure optimized for that type of lookup.
It was the capstone project for a Data Structures course, requiring the implementation of multiple structures from scratch rather than relying on Java's standard library collections.
The goal was to deeply understand how different data structures make different operations fast — and why there's no single structure that wins in all cases. By building the same conceptual index three different ways, the trade-offs between hash tables, sorted arrays, and trees became concrete rather than theoretical.
Every record insertion updates all three indexes simultaneously. Any update or deletion must keep all indexes in sync. This constraint made the architecture more demanding than maintaining a single structure, mirroring how real databases manage multiple indexes.
Full create, read, update, and delete support across all indexes. Updates are particularly complex — changing a student's GPA requires finding and removing the old entry in the BST and inserting the new value, while the hash table and name index remain unaffected.
The BST enables efficient range queries: find all students with a GPA between 3.0 and 3.5, or list all students in alphabetical order. These operations are O(log n + k) on the tree, which would be O(n) on an unsorted structure.
Keeping all three indexes consistent under concurrent modifications was the hardest problem. A deletion that partially succeeds — removing from the hash table but failing before the BST removal — leaves the data in an inconsistent state. Implementing proper rollback logic without full transaction support required careful ordering of operations.
This project made Big-O notation feel real. The difference between O(1) and O(n) lookup is invisible at 10 records but enormous at 10,000. Building each structure and then running comparative benchmarks made that concrete.
It also gave me early intuition about why database indexes exist and what they cost — every index speeds up reads but slows down writes. There's no free lunch.