Tables vs Spreadsheets

Spreadsheets are not databases

Spreadsheets are great when used correctly. Sometimes, all you need is to do quick calculations, or even organize information visually with headers, colors and whatnot. However, as practical as a spreadsheet is, it isn't the best way to organize data.

That's because spreadsheets do not really connect information in two very important manners, and they seriously impact the way an organization can scale up while still retaining data reliability.

1. Rows are not really groups of information

Spreadsheets are a great way of creating an organized list. If you create a spreadsheet with columns for Clients's information, it will seem very easy to keep this list tidy, apply filters and search for specific information. After all, each row will always have the same information: you know a client's phone number will always be next to their name, as will their email.

However, an important thing to keep in mind about spreadsheets is that their freeform nature has one significant disadvantage: it relies on the user to group the information correctly. As an example, I could put a client's website in his row, column D, but put number of employees on another client's row, column D. Column D, here, means nothing. It's whatever I type into it.

Also, nothing guarantees that row 4 only contains information about client Alpha. On cell E4 I may have part of a chart, and on column G4 I might have a quick note about a client that is actually on row 24 (it was just more convenient to jot something at G4 at the time).

Because they're so flexible without any kind of information grouping, spreadsheets tend to be as organized as the user, which can be a problem when working alone, but an absolute nightmare when working with teams: a spreadsheet will always be as messy as the most disorganized user, and sometimes keeping the Tasks sheet is just not that important for the Tech team as it is for the Marketing team. Different priorities wreck inherently disorganized tools.

2. Data isn't actually related

Spreadsheets heavily encourage the use of formulas for everything, from calculations to searches. And, because formulas are so intuitive and easy to use, it's easy to assemble something that kind of behaves like a database.

For example, one of the most popular formulas in spreadsheets is VLOOKUP, which looks for a value in the leftmost column of a selected group of cells and then brings a value that is a determined number of columns to its right. This allows a user to search the name of a client on a sale and retrieve their phone number or address, for example.

However, this doesn't really connect the two groups of information (sale and client info). You can't click on the client's name and see all of their history, or every other information that connects to them. That's because VLOOKUP merely copies text through a position based search: you're not connecting data, merely replicating it. What's worse: should you rearrage your columns, there's a good chance you'll screw up the formulas and have a screen full of Error messages.

How is Relational Data any different?

Tables in a relational database work in a different logic: every row is comprised of grouped data. If I'm looking a the Clients table, I can be sure everything in a row pertains to the same client. Also, all the data in the same column is of the same type, following the same logic.

But, more importantly, I can actually connect a row (or record) of a table to a row of a different table. So I can connect, say, Deal #0037 to client Alpha Company to establish a relationship between the two records. That way, I can access Alpha Company's information through Deal #0037 and use them to build dashboards and automations in a way spreadsheets can’t because they don’t store real relationships; they only copy data.

These characteristics of relational databases ensure that not only are they inherently more organized than a spreadsheet, but also more error-proof. You can create new columns or rearrange them, even change all the clients's names: data will still be organized and all relationships intact.