@ Prion re Import/Index differences and issues:
Size: In DEVONthink 2 there’s little if any effective difference in size between an Imported or Indexed database.
True, the database package size of an Imported database will be larger than the database package size of an Indexed database.
But that’s not relevant to memory usage and performance.
In the DEVONthink 1.x applications, some types of files were stored in the monolithic database, which had to be loaded into memory. Such files included text files, RTF/RTFD files, HTML, and WebArchive files. Therefore, an Imported database which held such filetypes had a larger memory footprint than did an Indexed database holding the same content. And Imported database could take longer to load into memory when opened, and especially if RAM resources were low, performance/responsiveness of the Imported database compared to an Indexed database with the same content could suffer.
The DEVONthink 2 database structure now stores all filetypes in the Finder, so the differences in memory footprint resulting from capture mode are no longer significant. Likewise, there’s really no difference in disk storage requirements, assuming in the case of an Imported database that the files copied into the database are subsequently deleted (which is what I do).
Portability: Because Import-captured databases are self-contained, the advantage goes to this method of capture if one wishes to be able to easily move databases among computers, or to transport or even run databases on external media. Because information will be lost if the Paths of Index-captured files are broken, moving the database also requires moving the externally linked files in such a way as to retain valid Paths.
I frequently do move my databases, so I prefer Import-captured files. This also simplifies backup. If I backup a database (e.g., using File > Export > Database Archive), I’ve also backed up all the referenced content as well; the compressed archive holds the complete content of the database. That would not be true for such a backup of an Index-captured database.
Organizational flexibility: I like total flexibility to organize and reorganize the group structure of my databases. Here, the advantage goes to Import-captured content. That’s because if I wish to use Index-capture and maintain synchronization of my database content to external files and folders, I need to keep the structure created by the initial Index capture of the Finder folders and files.
Considerations favoring the Index-capture mode:
Need to stay in synch with a structured source of new and/or modified data: Suppose it’s important to keep updated to a source of files such as a server to which new content is systematically added, and/or on which the files are sometimes modified (e.g., standard operating procedure updates). Here the advantage goes to the Index capture mode. Invoking File > Synchronize on the top-level groups on the server will update the database content. One could attach the Synchronize script to group(s) in the database, so that when such a group is opened it automatically synchronizes to the current content of the corresponding folder on the server.
Need to share files with another database or application: Example: if I used a citation manager database to manage PDF files in its database, I would likely Index-capture those databases rather than Import them in to a DEVONthink database. Now I can use the information content of those PDFs in my database without in any way affecting the operation of the citation manager, and if new items are added by the citation manager application, I can synchronize them into my database. Note: I would expect that some day in the future it will be easier to share content within a DEVONthink database with external applications. For example, use of URL/UUID file information allows access to a file contained in a DEVONthink database by some applications.
Two other points:
Spotlight compatibility: One has the option to provide Spotlight index metadata so that Spotlight searches can find content stored within a DEVONthink database.
A future release will enable cross-database use of Classify and See Also. This should add confidence for creation of multiple topical-oriented (or historical) databases.