I like baseball. I watch a lot of it. Actually, I’ve started to prefer listening to it on the radio since I don’t want to pay for cable just to watch the Mariners. It’s a great way to enjoy the sport. Either way, baseball broadcasts have always had a lot of random facts and stats pop up on the screen or read out by the announcer. You know what I’m talking about – true for any sport.
“This guy has the longest hitting streak on the team.” Ok, seems like that would be easy to look up. It’s probably scribbled on the back of the announcer’s beverage coaster. Others are more interesting.
“This is the longest hitting streak for this team since 1983.” Still pretty easy, I would guess. They probably have a lot of spreadsheet pages.
“This is the third longest hitting streak since 1932 where the hitter had a mustache and at least three of his opposing pitchers had played for 4 different teams with red in their uniform color.” Hey! That sounds like the beginnings of some SQL. But I’m jumping ahead a bit.
For my whole life, I had wondered how these stats get pulled out of thin air. I’m sure they had some clever spreadsheets handy. Maybe even a team of nerds and some worn paperbacks stuffed with tables of numbers. But it had felt for a number of years that the random facts were growing more ridiculous all the time. They defied any reasonable look-up method that I could imagine, anyway.
And then I learned about how databases work.
For whatever reason, I like databases. They are not the most exciting technology, but they are wonderfully versatile and powerful while being very understandable. Regarding my baseball stats ignorance, learning about databases was one of those rare, “Oh. Yes, of course. Now I get it” moments. That was a very satisfying little nugget of insight. And now – a database is warm, cozy place for me.
For this Capstone project we are using the MERN technology stack to build a web app. The “M” of course is MongoDB. Since our app was using JSON for its data transfer, it made sense to use a database which works with that format. This led to a bit of a winding journey in selecting the rest of the tech stack. Mongo was decided, but we were not married to the rest of MERN (express, REACT, node). The main reason was that we wanted to use python for a perceived ease of implementation. Two of our team had most coding experience in the language, so we were trying to minimize the learning curve. We even looked at Ruby as a potentially simpler language. Django uses python, so that was our main focus.
However, neither of these frameworks were designed to work with MongoDB. But such was our hope for python, that we pressed on with it for a week looking for a workaround before realizing that our reason for over complicating it was the wrong reason. If we wanted Mongo, why not use the framework that literally has it in the name? MERN it was.
I guess you could say the database was the seed for the design of our app. The ironic thing is that though I like Mongo, I have more recent experience with SQL. While thinking about the schema for our project, I kept being pulled into a relational database design mindset. I kept wanting to store different types of objects in different collections and then relate them somehow with document ids in other collections. Our application does not require that level of complexity, and after some mental struggle and advice from teammates, I understood that I was overthinking DB design.
The point, if there is one, is that the database must serve the needs of our application, not the other way around. What I was doing was trying to design a versatile database for a single use case that was yet to be determined in detail – i.e. make something easy to plug into once we figured out the details of the front end. So while I still believe a good DB design can be an anchor for a project, I needed a shift in perspective, and, consequently, a step out of my comfort zone.
Leave a Reply