Monica Wei

I‘d like to share two thoughts: one about the advantages of spreadsheets like Excel, and the other about the database-related jobs.

People say a database is a more advanced version of a spreadsheet/Excel, or a spreadsheet/Excel is a “lightweight” database. In reality, spreadsheets like Excel still have a lot of strengths when it comes to handling data.

First, it is super easy to use. It is visual, straightforward, and great for working with smaller amounts of data. It is much more affordable for small or even medium-sized businesses.

Second, I heard that you can share files and collaborate in real time using Google Sheets, which shows spreadsheets are also evolving.

Third, spreadsheets like Excel can work really well alongside databases. For example, a lot of data starts out in Excel before being cleaned up and moved into a database; You can use Excel to quickly generate a bunch of SQL insert statements; When data gets exported from a database as a CSV file, people often open it in Excel to check it or explain it to non-technical team members. Since almost everyone knows how to use Excel, it is a great bridge between tech professionals and other team members.

Also, Excel’s charts and pivot tables are really powerful. They allow you to turn data analysis results into professional-looking visual reports, which can greatly help when presenting your findings to others. This is another strength of Excel that is not directly related to databases themselves.

Regarding database-related jobs, I feel that if you’re good at SQL and know how to use a specific database system well, you can probably land a job as a Database Administrator or Data Administrator. These roles mainly focus on system maintenance or data compliance, and they’re not entirely technical. But if you also know how to use data modeling tools like ER/Studio or ERwin, you can go a step further and become a Database Designer, Data Modeler or even a Data architect. These jobs usually pay more and involve designing how data is organized and connected, which is really important for business.

However, If you combine database skills with Python (or Java), I think it’s another powerful mix. Databases help you manage data, and Python helps you analyze it. Together, they make you much more competitive in today’s job market, in jobs such as data specialist, data analyst, or even data scientist— position which offer good salaries and growth potential as well. That is what we are pursuing. Right?

(I used the thoughts on databases above as part of my class discussion this week, and I also replied to two classmates’.)

First reply:

Thank you for the questions! Honestly, I am still getting familiar with tools like ERwin and the details of data modeling, and since I have not worked as a database designer before, I am not sure I have a full answer yet. But based on what I understand so far, I think:

For a small toy shop, Excel might be enough in the beginning–it is easy and cost-effective. But as the business grows and things get more complex, switching to a relational database would be a better solution. We could then use the strengths of both Excel and the database system. For example, the database would store all the detailed info—like customers, products, and orders—in a structured way, making sure data stays accurate and connected. Excel could be used for input and quick checks, while the database would handle long-term storage and complex queries. Plus, Excel’s charts and pivot tables would help turn database data into easy-to-understand reports for the team.

Tables like Customers, Orders, Products are common for a business like a toy shop (and maybe an Employees table for schedules as well). The CustomerID would link the Customers table to Orders table as a foreign key, so we know which customer made which order. Similarly, ProductID would also connect products to Orders, showing what was bought. Keys like CustomerID and ProductID help keep data organized and avoid duplication.

Second reply:

Your table design and explanation already feel really complete to me！And I like how you thought not just about the core elements, but also about how the system could grow–like adding a suppliers table. That is very thoughtful.

It also reminds me of how these tables are connected and how they update in real time, since customers, products, and orders are all constantly changing.

I was also wondering:

If we ever wanted to track product returns or exchanges, would that mean adding more tables as well?

And in the future, if there is a need for inventory alerts–like when stock is too low or overstocked– would it be better handled as an extra attribute in the products table or as a separate table that just logs alert history? Since the Products table already includes a “QuantityInStock” attribute, maybe inventory alerts could be added there as an additional attribute—like a threshold value that triggers a warning when stock gets too low or too high. But we’d probably need more detailed info to make it work well, which could make the table more complex. So a separate inventoryAlerts table would be a cleaner solution.

Thank you!