Native documents vs. Documents database

1

Hi all, I’m looking for second opinions/additional perspectives.

The more I use Fibery the more I find myself trying to land a generic top level database (Task, Project, Idea) that can be given more meaning via specific fields.

I’m now considering creating a top level Documents database that could have a type field for things like: checklists, templates, contracts etc.

I’m curious if others are doing the same or are you the native Documents? If so what are your reasons for one over the other?

1 Like
2

I’m using native documents, but now that we have more and more documents, I’m going to need to migrate them to a documents database. I think that if documents are a readme for a space, so you only need 1 and you know you wont need more, then using he default document is the easiest. But now that we have a “docs” folder per space, it makes a lot more sense to use a docs database + smart folder. There’s really no reason why not and I thing it makes documents to much more powerful (you can add the status of your documentation, add comments field, archive, etc).

So essentially, if you’re using it to keep track of your documentation, and templates, etc, I’d recommend you make it a Documents Database, and use smart folders across your spaces.

2 Likes
3

I recommend using a document database option. It offers more flexibility with attributes and connections with other databases. It can also be integrated with the Highlight database, which can be useful at any time.

2 Likes
4

I use a Documents Database for most things, it’s my default. But of course you can always use regular Docs for one-off, specific purposes.

5

Overall we’ve made a strategic mistake when implemented Document as a View in Fibery. We had long discussions about how to fix it two years ago, but unfortunately it is not so easy (but we still want to do it in some future).

Document should be a Database conceptually.

So if you want to create Document Database, it is totally OK. There are some benefits and problems.

Problems

  • If you want to link this Document Database to some other databases, you will have to add quite many relations.
  • Database should live in some Space, so you will have to give access to this Space to all people (maybe not a problem)

Other than that, only benefits

Benefits

  • You can add some fields if you need (like Assignment, State, etc if you need them in some cases)
  • Automations are available (+AI in automations)
  • Smart folders with filters are available
  • You can create Views with Document Database entities (it may be handy for some cases, even Whiteboard View)
  • Semantic Search will work
4 Likes
6

A template of a documents database would be helpful. I’m having trouble envisioning how to set this up. Is the idea that the database would have a one field with the “Document” type, and then other fields could be used for document tracking/assignment, etc.?

7

I think most people who use a db for documents just have a single rich text field for the content, and then add any extra fields that might be appropriate, e.g. tags (multi-select), assignees, state (workflow), comments, etc.

The Fibery user guide is in fact a db with a 1:m self-relation to act like a traditional wiki with document nesting

3 Likes
8

I know this topic is a little old, but I thought I would add something since this seems to be a helpful reference for others in the future having the same question as the original poster.

Literally the only native docs we have is the welcome/readme page for our spaces. Every other doc is from our documents database.

Also, I totally took inspiration from Fibery’s user guide for using the self relation for organizing.

1 Like