One DEVONthink DB for everything versus multiple DB's?


New to DEVONthink Pro

What is the pro/con’s of having one massive DT db, and using groups for different things (e.g., journal articles, GTD references, personal finances, etc), versus multiple databases (e.g, db for all research/journal articles, a separate db for GTD reference stuff, a separate db for personal finances, etc)?

Would welcome any input / thoughts!

Thank you in advance.

The answer depends on your objectives. There is no right or wrong approach. If you have a lot of data that tends to be inter-related, then maybe that pushes the needle toward a large database. If your data are not related, then maybe multiple databases will work. (A recent reader was going to create several dozen databases because their work involved discrete projects.)

The AI (Classify, See Also) only works within a single database – not across multiple database. That’s another consideration if you plan to have DEVONthink auto classify or suggest similar bits of information for you.

For my work, I have individual databases at the client level, and lots of projects within each database for the tasks I’m chartered to do – this way all the research for all those tasks is in one place and I can make use of it across projects. And Classify works well within the individual client databases.

But, then I keep my private research in separate databases, my daybook in another database, etc. As time goes on you’ll probably find yourself creating new purpose-built databases, which is fine and probably pretty common.

(It’s a chore to split databases, so keep that in mind too as you think about the future. It’s a chore because it is not interesting work – :confused: – not because DEVONthink makes it difficult.)

Many thanks again, Korm. Hmmmm…Decisions, decisions, decisions…

Your comment about having one database per client and projects pertaining to each client within. Interesting. Do you set the projects up as group folders within the client database?

I had all of my research in one DB for the first few years (until fairly recently) – since I was still in the process of capturing everything, and verifying that my Reference Manager’s library was also up to date, and accurate.

I never really used the “See Also” functionality, since it hardly ever helped… Reason simply being that looking for XYZ would (quite correctly) pull up ‘hits’ from all 4 of my research groups, since the term would appear in all 4… But I would only be interested in what was said about XYZ in A SPECIFIC group – and since “See Also” would look at the entire DB, it was something I simply ignored, in favour of my tagging regime and smart searches.

Then I moved those 4 research groups into 4 different DBs. And all I can say is “wow”. The “See-Also” works a treat – it is uncanny how accurate it is.
Of course – at some point, I might play around and drop different “themes” from different jurisdictions into a new DB, just to see what the AI throws up, in terms of different countries applying similar rules/legislation etc. – point is, in DTPO, its incredibly easy to move things around, without fear – that these things become possible…

That being said, there is no “right” answer, unfortunately. In my case – had I started off with independent groups, and THEN moved them all into 1 DB, I would probably be here singing the praises of how the AI helped me find connections across jurisdictions that I would never have spotted in a year of Sundays… Whereas now, I’m doing the exact opposite…

I guess in the end I’m reminded of the 1st time I came to the realisation that, contrary to my initial belief (and that of many others who ‘kicked the tyres’, before moving on) – DTPO’s “steep learning curve” isn’t because of something inherent within the software… It’s inherent inside of you, the user! 8)

DTPO’s learning curve comes from you having to figure out what you can do with it, free from the preconceived ideas of how you have always been forced to think about your data… Once you cross that friction point, everything changes…

I’m rambling now… But maybe I still kind of make sense!?? Who knows… :unamused:

A follow up related: I’m leaning towards 2-3 separate db’s, however, I would love to use the sorter to drop various docs, etc. into the appropriate database, etc. Is that possible?

Thank you so much! :slight_smile:

I’ve tried different databases, but my work is all so interrelated, I haven’t been able to get it to work well. Now, I have one main database of current projects. It gets archived at the end of each academic year. I have a second one for research materials (an electronic library) that I reference, but I rarely modify the files. Both of them are indexed.

Ideally, I think I’d prefer breaking things up into several different, specialized databases. Things would run faster (not slow now, but the snappier the better), the sorting AI would be more accurate, and I could probably get away with keeping less on my local drive. But, I’m a big fan of replicants, wikilinks, the “see also” AI, and minimalist organization (the less work I do, the better). A single database gives me full access to all the features.

Cassady, you are making complete sense!! :laughing: I completely get what you’re saying. It is true that many of us (and I’m one of them) get caught up in the do’s and don’t. Since DT is flexible in how it can be used, I can see how approaching it with a similar frame of mind would be much easier…But since most software packages are not as elegant as DT and force us to work as they do, I suppose some of this is conditioned. There is a fear of screwing things up and finding you have to spend tons more time to fix the problem, or worse, lose valuable data. I’m s-lo-w-l-y learning that DT is somewhat different in that it is elegant, powerful, flexible, stable, and, well built. While nothing is 100%, Losing data is unlikely (especially with a good backup strategy). So, for me, I want to invest my time very wisely to leverage DT power to save me time.

I very much appreciated your input Cassady. Thank you very much!! Have a great weekend.

That’s the perfect use case for Sorter. Just drag Inboxes or groups from different databases into Sorter to configure it, then drop away :slight_smile:

Yes, sort of. My clients have several offices for which I do work, so I organize my database generally as

This is organic – the structure develops over a long period and I cultivate and prune the tree as time goes on, merging and splitting groups as needed. It’s a horrible waste of time, IMO, to configure a database with groups before you actually need the groups.

Outstanding :exclamation: I love it…This is going to be fun! :slight_smile:

I completely agree. I like your method…Seems a bit like David Allen’s GTD method, which I like myself.

Thanks so much for all of your support!