I am learning the DT system, and am considering switching to import rather than index, and one database rather than several. I wanted to see what would happen, what it would look like if I was forced, in the future to export them.
Thanks to BlueFrog, I was able to figure out the issues, but the export was a zipped folder with a DT database rather than a file structure.
but the export was a zipped folder with a DT database rather than a file structure.
Then you did a File > Export > Database Archive, which would be incorrect in this situation. Again, this information is documented. Menus > The File Menu > Import & ExportâŚ
As @BLUEFROG said, thatâs the documented behavior. If you want the structure in your file system, select the complete content of your database first (Cmd-A) and then choose File/Export/Files and Folders
Further up they said theyâve creating one database per chapter of their dissertation, which to me seems like a bad layout. Iâd have done one database for the whole dissertation, and then groups per chapter perhaps. Splitting the dissertation across multiple databases doesnât make sense to me when itâs all just parts of the same project.
Too much has been written in the One Database To Rule Them All versus many databases discussion, and mostly it boils down to personal preference, but as others have alluded to I donât want my household bills showing up in the same database as all my research for work. They are completely different types of file.
In addition to that issue, there may also be databases that you donât need synced to other devices. For example I have two databases that I only ever need access to on my computer and theyâre not synced, whereas my research database and a few others are accessible across all devices because I often need access when Iâm not near my computer.
The reason, which is the same as my indexing reason, is that I was unfamiliar with DT (or really using any database system). I am accustomed to seeing side bar separations of content; I am accustomed to separating things into folders and subfolders. I originally created new databases for each chapter simply to make an easy way to organize the documents as I was putting them into DT. In my mind, new databases didnât matter because if they were all open at the same time, then a global search would look through all of them.
For imported content:
A folder is a place in the file system, and its content is inside the folder.
A group is not a âplaceâ in the file system. Its content is not inside the group, but somewhere in the file system. The group is only, well, grouping it.
A folder is like a drawer.
A group is more like an album in Photos or a playlist in iMusic: It shows you items that you want to be shown together. Physically, they can be anywhere.
An item can belong to several DT groups if you replicate it.
And smart groups show items according to criteria that you define.
For indexed content, a group should be the same as a folder. I think.
Interesting. Could one import a file into one group, and then index it into other groups so that an edit in one group edits in all groups?
[What I am thinking of is a document that is chronologically in a group for the 1930s, but thematically would be in a group on race and segregation.] I would love to not have to choose which group to put it in, but I also donât want to have to have multiple copies so that highlights or annotations in one are not highlighted in another.
So, you first import file A in group A. That is a copy of file A.
Then you index file A in group B, C and D. That is a pointer (think âaliasâ) to file A.
If you edit the file in group A, how would that concern the file in B, C and D? These are not related in any way. Not possible. OTOH, if you modify the file in B, C or D, it should show the same modifications in the other groups (with the exception of A, of course).
Thatâs what replication is meant for.
All this has been discussed many times already, it is explained in the documentation and probably in much of the other reference material already mentioned in this thread. Thereâs little point to repeat it all again. I suggest you start reading through the documents mentioned here first and then ask more specific questions.
Itâs unusual but there is actually nothing wrong with this approach, if it makes sense to you and could effectively use it. However, unless youâre only working with a single book, that would lead to many more databases. A database per book would still be unusual but less so, with groups for chapters if you wanted that kind of subdivision. More commonly youâd see databases per topic like Physics or still specific but broader, MIT - Post Grad - 2024-28.
These kinds of divisions are recommended over an enormous JMC2 database containing everything and anything, personal and professional and academic.
And then thereâs the drawback that items canât be replicated across databases. So, a single database for a book with groups for the chapters might be easier to handle, if replication is desired.
Agreed. As with many questions about DEVONthink, the reply (and yes, I specifically didnât say âanswerâ) often begins with âWell, it dependsâŚâ
@JMC2
On a related side note: If you were working through a book in PDF format and wanted to process each chapter separately, the Tools > Split PDF > Into Chapters command would break it up into one PDF per chapter if the PDF has a table of contents.
You could even do this with multiple PDFs in the same database, grouping the chapter documents however youâd like. Itâs all up to how you work.