korm’s comment above is correct: Classify and other tools for filing are available in DEVONthink for organization, whether documents are Indexed or Imported.
Every now and then I tend to reorganize a collection of documents, either to improve the functional meaning of the organization to me (and, hopefully, to Classify), to move documents from one database to another, or to prune obsolete or less useful references. That can get confusing for Indexed items, especially if I want to move some but not all the contents of an Indexed group to a non-Indexed group, or to a different database. The confusion is amplified if I need to keep the corresponding external files and folders untouched except, perhaps, moving some items that appear only in a database out to an Indexed folder. I try to avoid puzzles about what “belongs” where, so I feel constrained about reorganizing Indexed items. Tip: When in doubt, replicate rather than move Indexed items (but replication doesn’t work across databases).
But the largest constraint on reorganization is on the external files & folders. Renaming Indexed folders or files will break DEVONthink’s paths to them and result in those “missing file” errors. So will deleting those external items, as will moving them outside their existing hierarchy. The safest approach for organization of Indexed folders and files is to place them within a top-level folder the name of which doesn’t change, and Index that folder.
Re access to Imported files by an external application: Yes, while any file in your database can be opened under an application capable of opening it, using commands available to the user, there are limitations here. For those (few) applications that can properly interpret DEVONthink’s Item Link, that’s a good approach. DEVONthink databases store files within the Files.noindex folder inside the database, using Apple’s filesystem. At first blush, one might think an outside application could link to the path of an application stored in Files.noindex and access it whenever needed. But for performance reasons, the paths to those files can change. Se we have to caution that this approach is unreliable.
Re reasons for creating multiple databases: The original reason I split my document collection into multiple databases was for performance, as my old TiBook had only 1 GB RAM, and it slowed to a crawl when asked to work with a large database. My current MacBook Pro Retina with 16 GB RAM, but as I have about 250,000 documents among all my databases, it would choke on a single database that attempted to hold everything.
There are other valid reasons for creating databases that meet a specific need. My research collections hold references and notes about different topics. The performance of Classify and See Also is improved by those topical designs. I have other databases in which Classify and See Also don’t work well, but are irrelevant, as in the case of my financial database, which holds, e.g., invoices and receipts classified by tax year.
