How to model your Baserow data: general guidelines + examples 🧩

Tips&Tricks
, ,
#1

Data modelling is the art of designing table structures that properly and efficiently store data. In the context of Baserow, this is the process of deciding what tables and fields you should create in your database to best represent your data.

What guidelines to follow to keep your data structured well?

  • Never store multiple values in one cell unless it’s a field type that specifically supports that
  • Never manually add the same data twice
  • Avoid having empty cells

All the explanations along with the examples are well-described here: https://baserow.io/blog/how-to-model-your-baserow-data.

And let’s thank @Alex for preparing this useful tutorial for you all! Share your feedback in the comments :point_down:

2 Likes
#2

Unfortunately, some of the design and UI limitations around row linking and multi-select fields actually encourage bad practices this post tells you to avoid.

I’m hoping future versions make progress on addressing some of that.

#3

Hey @dkonigs :slight_smile:

Could you explain in more detail how they encourage bad pracices?

The row linking and multi-select fields are actually represented as a many to many table under the hood, so technically they don’t break any best practices, they just present data more easily to the user.

Please let me know your thoughts :slight_smile:

#4

Oh, its not the under-the-hood parts. Its definitely on the UI side.

For multi-select fields (or even single-select drop-down fields), there’s no way to have a “common” list of choices used in multiple places. So if you have a bunch of items for which the same options are appropriate, you have to redefine the whole list multiple times.

For row linking, just try adding a link to an item in a table with more than a dozen rows. You end up having to click “next” a dozen times, or maybe even hunt around. The whole process of finding the item to link is way too tedious, since you can’t yet define any rules for what options are presented. A lot of this could be fixed by writing code to build a tool that sets up links for you, but doesn’t that kinda defeat the whole purpose of “no code”?

#5

For the multiple select, we have received requests in the past of people asking to make the choices dependent on another Baserow table, which would actually resolve the issue you are referring to (I would say?) so it might be worth looking into that again.

Regarding the link row, I can understand that manually linking can be tedious, but I don’t think I understand how that violates data modelling best practises, could you elaborate further on that?

#6

I’m well aware of the multiple feature requests related to selection choices. But just because its been requested, doesn’t mean it exists as a feature as of today. As of today, you still need to needlessly duplicate the selection list.

For link rows, no it doesn’t violate best practices. But the UI still makes it very tedious to actually follow those best practices. (And yes, I’ve already written some feature request posts about this very issue.)

#7

Just to clarify

so it might be worth looking into that again.

Was meant as in “maybe we should reconsider adding a feature like that”.

Thanks a lot for the feedback @dkonigs, hopefully we will be able to resolve these issues to make it easier for users to follow the outlined best practices :slight_smile: