During the initial stages of my group\u2019s project, I\u2019ve taken on the task of designing our database structure. In a couple of recent courses I\u2019ve done some back-end development to store some entities in a data warehouse. However, I haven\u2019t had to put together the details so specifically in an ERD or schema since the databases course. Over the past week I\u2019ve spent a lot of time reviewing database concepts, but all that review didn\u2019t prepare me for something I haven\u2019t had to do yet: make actual decisions about the type of database to be used and the framework used to make it.<\/p>\n\n\n\n
The differences between NoSQL and SQL were certainly covered in the databases class, but I don\u2019t think the decision had been left to us for that class\u2019s project. It\u2019s been interesting to be faced with options and delve into some of the reasons to choose a particular framework, hosting service, etc. Don\u2019t worry, I won\u2019t bore you with an exhaustive list of all of the pros and cons of these choices. As a novice programmer, I find these kinds of decisions to be the most obviously challenging part of the profession. Sure, almost anyone can learn how to implement all sorts of data structures in a variety of languages, but knowing exactly when to utilize each of them is the hard part.<\/p>\n\n\n\n
I felt fairly lost reading through descriptions of various DBMS. The scale of my group\u2019s capstone project is fairly small, so a less-optimal choice for a DBMS would likely not set us back too far. However, I think we made the correct choice to use a SQL database and PostgreSQL as our DBMS. Our data model is almost guaranteed to stay fixed after the initial schema is set, the data is not hierarchical, and we\u2019ll likely need to perform some complicated queries on the data [1]. Even if PostgreSQL isn\u2019t perfect, it\u2019s a DBMS that I haven\u2019t used, so I\u2019ll be eager for the chance to see something new (that will certainly be acceptable for our project).<\/p>\n\n\n\n