Indexing

I really like keeping separate DT databases of various topic areas (keeping home separate frpom work for example), but sometimes its a pain needing to open another database to remind myself whats where, cant I just take a ‘peek’ from where I am? My own categorisation is not always 100% :slight_smile:

I know we can index volumes and directories without importing them. What would be handy is to be able to index all my separate DT databases, keeping in one sense a master DT file that is very small and portable, but lets me finds documents across all my databases. When I find what I want, the appropriate database is loaded (or requested if on an external volume). This index of my entire collection could be accessible from any of the databases via a panel and auto-updates, so if I dont have a particular database file with me I can still locate it and relax knowing I already have that data back on the computer at work/home.

So will DT 2.0 have this ability?

Version 2.0 of DT Pro will be able to open multiple databases concurrently and to search all of them but there won’t be a master index (because a “master index” would be either just a reference to other indexes which have to be loaded or would contain all of the referenced indexes and therefore would have no advantage over one huge database)

Andrew:

Not likely in version 2.0.

Spotlight could let you “peek” in DT Pro version 2.0 databases, but only if what you are looking for is on a volume accessible to Spotlight, or in a smart folder from a previous Spotlight search.

I presume that means in terms of memory/resource/performance, having multiple databases open is not a problem versus some sort of constantly updating index file accessible from any single open database?

Bill, the Spotlight option is good, but surely that eliminates many of the custom and fuzzy DT search options available (or will that be addressed by a Spotlight/DT plug-in?)

Unfortunately, neither option saves me from having to carry all the databases with me and opening them all at once, which could get unwieldy in terms of size. I like the idea of carrying my current project/research database only, while the old or static projects (which may have something relevant) are stored back at work should I need them.

I look forward to DT2.0 :slight_smile:
Thanks.

Surely there must be some way for me to index or replicate a file or folder from one database to another. Please say it is possible–and tell me how!
Thanks!

Joseph

No, that’s not possible.

A replicate is an interesting concept in DEVONthink, as it is a means of allowing multiple instances of a document, each of which refers to the same file – and that file must be located within the database. Why can’t the file be located in another database, as you request? Because each database is independent of others, so that they can be individually opened, closed or, for that matter, deleted without affecting other databases.

Because DEVONthink databases are dynamic in structure, for performance reasons, attempting to Index a file stored in one database into another database would result in broken Paths. That doesn’t work.

I have a number of databases, each of which is designed to meet a specific need or interest. Given my design approaches, it should be a relatively rare circumstance were I to capture the same document in more than one database. Which is to say, my databases don’t overlap each other in content, which seems to be implied in your request.

In a very few cases I do duplicate a document in more than one database. As this is not common, it wouldn’t be a significant addition to overall file sizes of the databases. An example might be a reference source that contains segments related to more than one database. I doubt that I’ve incorporated such items as duplicates in more than 4 or 5 instances in the many years I’ve been using DEVONthink.

Think about two alternative approaches, if your database designs require overlap for some reason. (I always question my design approach if overlap raises its ugly head.)

  1. Index the same Finder files or folders into two or more databases. Although the index and metadata information becomes duplicated, the files or folders themselves are not duplicated.

  2. Once in a while a document that I consider a primary reference in one database includes some information that I consider highly relevant in a different database. Rather than duplicate it into the second database, I will create a note about it within the second database that includes a searchable summary or excerpt related to the purpose of the second database, and that includes its Item Link/Page Link in the first database. I think that approach makes for more efficient use of the reference in the second database than a copy of the entire reference.

Thanks, Bill.
Yes, I am still working through my “design” of databases. I’ll look again at eliminating/minimizing the need for overlap.

BTW, I wasn’t aware that ‘gators live in Indiana :wink: