Bases -- why have more than one?

I don’t know if I’m missing something, or overthinking something, or if maybe this is just planning ahead for further development, but…

What is the point of having to create and name Bases if a Base just contains every file from the vault regardless? There’s no point, then, in creating more than one base, right? Just different views?

A base usually doesn’t contain every file from the vault, you would typically add filters to it to only show notes that relate to what you want (can filter by folder, property, tag, etc). For instance, I have a base that only shows notes related to health appointments that are all stored in a ‘Health’ folder. It’s similar to how you would filter notes in DataView to only show the ones related to your current need.

1 Like

This is the first .base I created when Bases came out and was testing things out:

In addition to what jpfieber mentioned, I now have many more with different filters and Properties displayed. Keeping everything in one .base using only different views would have been unscalable and quite difficult to use IMO.

3 Likes

It seems that having too many views, filters and formulas in one base file would make the base work slower. I guess it is because the base engine needs to read from the file when you make any changes, and if the file is too big, it can affect the performance. I only had this issue with very complicated bases, but generally it is safer to have smaller base files with the limited amount of views.

It was my understanding that a base DOES technically contain every file from the vault, while views do not. So why create separate bases rather than just separate views?

Because it’s not convenient to choose from 50 views?

1 Like

In my experience, many of my views have a set of filters in common. For example, I have a set of views that organize my active projects in different ways, and I have a set of views that organize my contacts in different ways.

I find it helpful to have a different base for each set of views, because each base can provide an underlying set of filters shared by all the views (e.g. select all my projects, ignore completed projects; select all my contacts, ignore inactive contacts). If I need to change the underlying set of filters, all of the views that use it are updated automatically.

4 Likes

Most of my bases are for specific types of notes that I filter further down. An easy example is a “projects” base. Rather than one mega-base with many filters of which 5 or so pertain to projects (for which I would have to name something like “Projects: In Progress”), I have a single base dedicated to projects with filters like “In Progress”. Reiterating what I think has been communicated thus far, it’s a convenience. You can apply one set of filtering rules to multiple different filters. However you make sense of it is up to you. I like to think of it as “I make a base for X type of notes and use views to show X type notes that are A, B, C… Z”.

I maintain a single folder for all my bases, but I could see others wanting to place bases in specific folders if it fits their scheme better.