Overview
A full-stack web app cataloging every stock team and player in Super Mega Baseball 4. With click-to-sort table headers for every stat, full search functionality, and filtering queries, users can find exactly which players would fit their team best. In a game that depends on community-led leagues and drafts, this is a helpful tool for any player.
What went into it
I used this project as an opportunity to gain proficiency in SQL as I explore career opportunities in data and analytics. The database is made up of two seaparate tables - teams and players, connected by a foreign key.
That foreign key had to be made nullable to eventually add free agents, so I immediately recognized the need to make deliberate design choices on which keys should be nullable. There were times I changed my mind about these choices, and needed to
make schema changes after real data had already been entered. I learned to use Alembic, a migration tool that tracks structural database changes as versioned, reversible files, which made late changes much simpler and less dangerous for
existing data.
Most of my schema work went through SQLAlchemy, which let me define tables as Python classes instead of writing raw SQL for each change. It was a good way to get comfortable with relational concepts without needing to be fluent in SQL
syntax. When it came to transforming the data sitting in those table, like splitting name into first_name and last_name, I wrote a bit of raw SQL inside the migration file itself. Using SELECT to pull existing
values, then UPDATE to re-enter the names, split by spaces. That gave me great insight into the convenience of an ORM vs the control of raw SQL.
Working with PostgreSQL directly, via Neon's SQL editor, was great for fine-tuning. Sometimes there would be a typo on a single or a few values, and fixing those as direct, one-off SQL statements taught me more about the actual query syntax than working
with an ORM could. I also learned where JSON columns can be helpful (short, player-specific lists like traits or pitch types) versus a typical many-to-many relational setup.
DB Host: Neon | Backend Host: Render | Frontend Host: Vercel
Future Outlook
I'd like to add a login system and several user-specific features, like the ability to upload custom teams/players.