Rows not based on files

[ryanwwest]

I really enjoy using this plugin but often want to create some database with lots of rows, but don't necessarily want to create the overhead of having one file for every single row. Having a 1:1 row-to-file mapping creates inefficiencies such as overfilling Obsidian's link autocompletion dropdown or note quick switcher and seems like a lot of extra bloat in the file system.

Now, I completely see the value in allowing a row to come from a file, as this allows the row to utilize all of Obsidian's linking and interconnection features. The dataview and YAML support are excellent, and I use these regularly. I just wish there were a way to have (possibly less important) rows in the database that do not need their own file as well. For example, I have a database of books I've read or at least looked at in some way. While I love being able to have complete files for the books I read and have summaries and additional (non-columnar) text for, I'd prefer to track books that I didn't complete (and don't want to dedicate a whole file for and thus see in file search results) in the same database but not in their own dedicated files.

Exactly how this would work could depend - perhaps store the row information in the parent database file, and have the option to migrate a row's contents into a new associated file (including putting the rows into YAML or inline Dataview fields). For a more Markdown/exportable option, you could potentially store database file row results in a Markdown-style table, but I also think those tables are pretty hard to use.

I understand this might be a fundamental shift away from how this plugin works. It seems like Notion tables might offer what I'm looking for, though I'm not positive.

Has anyone else wanted functionality like this, or is there another thread that discusses it more?

[RafaelGB]

Hi @ryanwwest ,
the idea has potential but we have a core problem here since the plugin use dataview as search engine. I think it not support "shadow" rows.

About the use of another sources, maybe the solution could be CSV , use that format as source of information could be useful. Currently you can import/export your table to CSV, so we already have a solid base

[ryanwwest]

Yeah, I expected that this would be a major fundamental change and understand if it would be too hard to implement. But I am curious if anyone else would like something like this or has alternatives. Thanks for the idea on CSVs.