As we discussed in the prior tutorial, we interact with data and databases throughout our lives. We asked you to think about what you interact with on a regular day but let us take a look at what that could consist of for an individual:
Before going to school, Jeff checks his class schedule for the day as well as his work schedule after school. The class schedule is stored in his university’s database system while his work schedule is stored in his company’s database. While going to school, he picks up breakfast at a drive-through at a fast-food location with his credit card. Consider how those menu items are stored and the restaurant would track purchases. Since Jeff paid with his credit card, consider how the transaction would not only be tracked at the restaurant but also set up a transaction with his credit card company.
When Jeff arrives at school, he has to take an exam through his university’s learning management system for his math class. Think about how the user accounts would be stored and mapped with the course/instructor as well as the exam storing the questions and responses for each student. After his class, he plans his trip to go home for the upcoming break and books train tickets home. Consider what data the train company would store for the train schedule and for the purchase of the ticket. Just halfway through Jeff’s day already, he has had to interact with a significant number of databases that we have identified so far.
Try to really map out what you have interacted with so far, are there apps that you use or games that you play that would also track your data? How does your news get delivered to you? What about the messages that you send to your friends and family? The list just keeps on growing!
Even given the databases that you interact with on a regular basis, it is important to differentiate when we may need to use a database and when it may not be needed to do so. Databases should be used if it is a new tool or purpose where we may have various types of users that would interact with it. Users may need to just query from a database (such as a product list a company provides to view) or also need to insert, update and delete from it.
On top of that, if a company already has an existing application or database, we most likely would not to create a separate new database but build on top of that existing option so that we can avoid data redundancy. For example, if a company has an eCommerce site with a database that already exists, it will not make sense to build a separate database to track newsletter signups from those customers. It most likely would make more sense to add a field or table to the existing database to help track that newsletter signup process. If we are able to add tables and fields to an existing database, it would be simpler to do so over creating a completely new database.
Note that this can depend on the organization especially if there are third-party resources being used as the organization may not have access to make changes to the database. If this is the case, they may need to create their own if they need to do so for a different purpose. If the purpose of the business need is for a specific scenario, it could be more efficient to use other tools to track like Excel.
If it is a new application that they are building that cannot be added to an existing database, it would be more required to create a new database. If we are able to use simpler tools for one-off scenarios or simple scenarios, it may not be the best approach to create a database for although we certainly could do so.
Source: Authored by Vincent Tran