I’ve just started many DT trial and have been playing around with bringing in a number of files that I’ve traditionally stored on a NAS.
However, it feels like I’ve only brought in a small amount of docs so far and I’ve got a database that is already 11GB. So I guess I have a few questions, which are going to be pretty basic but I’m just trying to get a better understanding of how DT works and how to make it best work for me:
How does DT actually ingest files in relation to the size of the database? Obviously the more I ingest, the larger the database will be, but the DB size is still smaller than the files are taking up. So is this just a massively efficient compression engine, or is DT not actually talking in the whole file?
Where do people tend to store their DB’s? Do you put on a local HD or are you tending to store it in a Cloud solution? I’m just thinking that if I put my entire archive into DT, then it could potentially take up a significant proportion of my MacBook’s HD.
Recommend that before you go any further, get copies of and read the DEVONthink Manual and the free-of charge (compliments of DEVON Technologies] “Take Control of DEVONthink Pro” from their web site.
DEVONthink, unlike other apps, does not modify the files you bring in. It does, however, add new information ABOUT the files to enable its features to work for you, e.g. searching.
Also, DEVONthink uses different nomenclature than “ingest”. They say “import” and “index”. Both fully explained in the Manual. If you use “index” for files, be sure to read and understand what you need to understand, per the Manual.
The databases, per the Manual, should be on the local drive and you should not put them into a “cloud” location. To do the latter risks with probability higher than I’m willing to put up with that the database will corrupt. See the Manual.
Yep. It will take the space it takes. Do you need to put the entire archive into DEVONthink? You could put “old” stuff into databases, then archive those databases to your NAS or something. Recover those databases when you feel the need to find something old.
Risk of a big drop in service. Probably you’ll have a self-inflicted corrupted database (due to the way cloud synchronisation works, or access to remote files via the local/inter “net”.
