Your comment that one cannot replicate items across databases is true. However, given the organization and topics covered in my multiple databases, there have been a few cases in which Iāve stored an item in more than one database. Not often, perhaps only a handful of instances.
Your comment that one cannot search across databases isnāt true. I prefer using the full Search window for searches, and it can search across all open databases if desired (as well as making inspection of all search settings easier). If each database has the option to create Spotlight indexing checked, a Spotlight search can be performed to search across all databases, including closed databases. Tip: when Spotlight displays the search results, chose the option to view all results. A Finder window opens, and the results that are within a DEVONthink database will display the blue shell icon. Select such a result and press Space to see a Quick Look display, or double-click to open the item within the DEVONthink environment.
Your comment 2) about separation of work and personal information can be meaningful. When I first started using DEVONthink back in 2002 I worked in a governmental agency as a division administrator. Under law, all work-related issues, especially those involving regulatory issues, were subject to subpoena. I kept such data in a separate database (yes, that was possible, although unwieldy, back then and became much easier when DEVONthink Pro was introduced). Thereās another set of data that Iāve always kept separate, relating to past activities in conducting seminars that included federal personnel in the NSA, CIA, Secret Service and DoD. Even the names of some of those persons remains sensitive information.
Letās talk about your reason 1) for multiple databases. A single database may well be feasible in terms of performance when one starts out. When I first started using DEVONthink, I was using a TiBook with 1 GB RAM and fairly limited storage capacity. As I continued adding content I stretched the capacity of the TiBook to its limits. My next Mac had 2 GB RAM and a larger drive, then 4 GB, then 8 GB and my current MacBook Pro Retina has 16 GB RAM and a 500 GB SSD. But over the years Iāve accumulated more than 250,000 documents in a number of databases, some of which I rarely need to access. Were I to try to manage that collection in a single database, my current Mac would slow to a crawl, and I suspect it would frequently run out of free RAM even with a capacity of 32 GB RAM. For that matter, if I stored all those databases on my computerās internal drive, its capacity would be strained. Many of them are kept on an external drive, available when needed.
Designing multiple databases allows for growth of document collections in manageable āchunksā that can fit into the capacity of oneās computer.
Now letās talk about your comment that topics within a single database can be separated by group. Yes, thatās true. But it can result in less effectiveness of the AI assistants that I often use, especially See Also and Classify.
My main database is the one I most often use for research and writing. It reflects my professional interests of long standing in environmental sciences and technologies, environmental case studies, policy issues and environmental law and regulation. It contains about 30,000 documents covering a number of scientific and engineering topics, case studies, policy papers and reports and environmental law and regulations (principally U.S. and EU). The total word count of this database is more than 40,000,000 words (about the size of the Encyclopedia Britannica). Iāve been lovingly pruning and updating this collection for many years.
A separate but related database contains methodological topics such as environmental sampling procedures, sample analysis procedures, environmental data analysis procedures (statistical and quality assurance procedures), risk assessment methodologies and cost-benefit methodologies.
Why did I separate those materials? One reason is that combining these two large databases would result in performance slowdowns. But thatās not the really important reason. If, for example, Iām researching a topic such as mercury contamination in edible fish, I want to look at toxicology, case studies of human health impacts and existing or proposed regulatory limits. When I do a search or invoke See Also in that database, I donāt want to be distracted by numerous references to sampling procedures, sample preparation, analytical procedures &c. Likewise, when Iām researching issues related to sample preparation for analysis of mercury in fish and choice among analytical procedures in the other database, I wouldnāt want to be distracted by essentially irrelevant issues including toxicology of mercury &c.
By separating the topical coverage of these databases, Iāve increased the effectiveness of DEVONthinkās tools for helping me work with the information content of each of them. Iāve got a number of other databases that meet other needs and interests. I donāt capture every file on my computers into a database, however, as many of them are of little or no importance for adding value to my databases.
DEVONthink provides two very distinct methods for capture of documents. Import copies the documents into a database. Index creates Paths to the documents, but they actual files remain external to a database. Both are valid approaches. My personal preference is for Import, so that my databases are self-contained. When I capture a document from the Finder, Iāll delete the original file, or archive it to an external drive. I donāt use citation manager software. Iām old school, having worked with publication of massive bibliographies and with citations in published papers in the days before computers were available to individuals. I make sure that the information necessary for footnotes or citations of every document I collect is available, if needed. My databases have always been very stable, and of course I use a multiple backup strategy (Time Machine backups and also Database Archives of the most important databases).
As always, others are free to consider my personal preferences and workflows eccentric, and to choose approaches that work for their own needs.