Relational Databases are a way of connecting data and establishing a relationship between them. Or, simply put, defining how one block of information relates to another.
To show the meaning of this in a more practical manner, let's go through a simple example:
If we look at the Clients table below, we can see that it's a simple table that's totally self contained. That is: I have no information besides what I'm seeing on the table.
However, there's certainly more important information to know about a client than their contact info. If we're a SaaS startup, for example, we might have different plans that the clients can subscribe to. If that's the case, we might want to add a "list" type field called "Plan" to indicate this. It would look something like this:
At first it might seem we solved our problem, but there's one thing we still have to take into account: the characteristics of the plans themselves. Of course, we could just add more fields (like pricing, maximum number of users, features), but that would not be ideal for two reasons:
I'd have to unnecessarily write down the same information many, many times: every client with the Smart plan, for example, would have the exact same features, and I'd have to copy it every time I added a new client to our database;
It's very easy to mess up and very hard to correct: because I have to input every information manually every time, the chance of human error increases exponentially. Also, if I change some characteristic of a plan (say, pricing), I'll have to edit each client manually, furthering the chance of something going wrong.
However, a relational database allows me to do something else: connect tables. I could, for example, create a separate table for Plans:
And then *connect the Clients table to the Plans table to indicate this relationship using a "Connect tables" field, which would look something like this:
Not only can I choose from the plans in my database, I can click on the plan directly from the client record and see the plan's information. Because I've established the relationship between client and plan, I now have access to the information directly should I want to use it (whether for a quick glance through the interface or for automations).
Now, the way we built the relationship above is that every client can point/connect to a plan. So what happens if more several more clients choose the same plan?
This information is also available through the plans's table. If I open the "Smart" plan, for example, I can easily see which clients are subscribers to that specific plan:
What Relational Databases do is allow you to create those connections in a way you can better organize and use data. Traditionally it would be necessary to hard code these relationships when designing a process, but jestor allows you to create them through the UI with just a few clicks.
Understanding connected data
If you'd like to know more about how to effectively use Relational Databases to build processes, we strongly recommend that you read the Three Laws of Process Building: https://jestor.com/blog/jestor-process/pareidolia-to-process/
Updated over 1 year ago