I need som advice turning one db to several

Hello,

First of all many thanks to this great community. Checking in here from time to time to learn stuff, from you the community and the great support from the devs. Most software do not even come close to this dev-involvement in the discussion.

Have used DEVONthink for almost four years. Since then one database have getting to large but mostly to widespread of topics. For future sake it’s time to make one database to 3-4 smaller ones.

To my question: does anyone have any tips and tricks / opinions how this transfer of files most easily is done? All files is tagged (almost 5000 in total), some files have 2-5 tags. Can I use the tags-‘dropdown’ to drag and drop to another database specific files from specific tags? Or is the right way of doing this to individually drag and drop each file to the new database? (hopefully not haha).

Interested to hear someone else than myself have some input, hopefully.

Many thanks in advance,
a happy DEVONthink user from Sweden :slight_smile:

1 Like

Hi. I fiddle around with databases like this all the time, but I have a fairly simple structure, so someone with more complexity could give a better-informed answer, but for starters, how about:

(1) creating a few empty groups (depending on your organizational structure),
(2) creating a rule to identify the files you need,
(3) dragging them into the groups, and then
(4) dragging those over to the new databases?

If it is a one-off move, I think there is no need for scripting. Whatever you do, I recommend you make backup(s) before any major work (this goes for big changes in any app).

One caveat would be if you have some complexity like a bunch of replicants and/or indexed files. I’d test whatever method you choose before you start moving those around.

1 Like

Upon a suggestion from @BLUEFROG on another post, I found it was a matter of creating a new database and using drag&drop of items from one db to the other.

1 Like

Indeed, this is the easiest method though I do recommend moving things in smaller batches that thousands of files at once.

Welcome @utiPontushage
The tags are applied to the documents so when you move them to another database, those tags come along with them.

I’m not sure what “tags dropdown” you’re referring to.
While it’s not something commonly done in this manner, yes, you technically can move a document from a tag group directly into another database. More commonly, items in the databases root, inbox, and groups are moved, not via the Tags group.

You could also drag and drop a tag group from one database into the Tags group of another to transfer the documents. Consider this…

Document A has tags one and two.
Dragging tag group one to the Tags group of another database would transfer the document in the database, the one tag and the two tag since it’s also applied to the document.

Many thanks for your time - much appreciated :slight_smile:

Will take your input with me and start with this work in the coming days.

and yes @BLUEFROG, the tag group was what I meant :slight_smile:

Again, thanks all of you!

You’re welcome and make sure your local backups are current before you proceed.

Yes! Can’t say i’m good at many things but backups is my forte.
Thanks @BLUEFROG

1 Like

I’m going to be that person (someone has to be!) and just ask: what is it that you are trying to achieve, that you think separating out your databases will help?

There are valid reasons for doing this so I’m not suggesting you shouldn’t do it, but as someone who had to amend all their data structure early on in their DT journey I feel it’s worthwhile asking “why” before you do anything!

5000 items isn’t that many (in the scheme of things), and perhaps you just don’t have a structure in your current database that works for you.

Personally. I run one main database at present, with several smaller ones that do very specific things that I don’t want mixed in with my main database. My main database is basically where ALL knowledge goes, which includes work, fields of interest, random things. But I have a rigorous structure (folders and subfolders) so everything has a clear home. Arranging my data like this means sync across devices is easier (one database versus 4, for example), manual backups are easier (one database to verify and export), I can link and navigate files easily, and I can use duplicates and replicants as needed to keep files visible where I need them.

But there are many people who are more at home with one database per topic, or a clear line between work stuff and personal stuff, for example.

1 Like

Fully agree with @MsLogica here. After years of using DEVONthink, I’ve evolved with a few db’s as @MsLogica describes. Everything is simpler, and more importantly to me is with “bigger” db’s replication into multiple groups is possible, avoiding duplication.

So, the “why?” and “what problem do I think I’m fixing?” are an important questions for @utiPontushage to consider before doing anything.

Not that once the db’s are separated, one can’t easily go back to fewer/bigger ones, as I know all too well. Easy to drag and drop back into fewer db’s.

1 Like

Doesn’t this boil down to preference? Some people are splitters who like to separate and categorize, and others are clumpers who like to put as many similar things together as possible. (And some people, like me, go back and forth.)

Thankfully, with DT and other well-designed data management tools, you can eat your cake and have it, too (a revised, more understandable version of the old adage). You can create scads of different groups or sub-groups, arranged hierarchically if you like, and then employ tags and smart searches to associate the documents in the groups, perhaps using replicants or duplicates to let you “file” something in more than one place.

Or you can put everything in one big bin and use tags and smart searches to differentiate the contents.

Or you can come up with some kind of hybrid system which accommodates inconsistency in filing and labeling practices.

In reality, your data, unlike your papers filed in folders in a metal cabinet, are just in a big digital heap anyway, right? (Or – and I’m going out on a limb here – maybe your data are scattered in a zillion places but in units with pointers, imperceptible to the user, that reconnect the parts.) Regardless, no matter how you set things up, you’re using the equivalent of labeling only to simulate categorization or hierarchy.

(This is a retired English teacher talking, so if one of you actual CS people wants to set me straight, have at it.)

1 Like

Thanks a lot for additional input :slight_smile: Everything is considered.

@MsLogica and @rmschne legitimate questions! I believe many people interested in this tech stuff with all that follows never is satisfied. Always in hunt for better apps, better workflows and better structure as a result of that. I’ve been there, done that (sort of, i believe haha). Just to get that aspect out of the discussion.
I have in total 15 databases. Most of them with at least 2500 files and some many more. All in different categories. Some personal, most research related. The database that is involved in this discussion is the one that I feel have too many branches and not because of the number of files in it today but for future sake start organise it now when it’s easier done (and I am on paternity leave with more time at home :wink: haha). I understand your point and that’s exactly the way I have gone with different tech-stuff. With my files, my research? I will go with more databases BUT stop there. That’s my ambition.

English is not my first language and to write it is harder than to understand / speak - in my world at least. Hopefully i made it pretty understandable.

What did I do? I have started the process of moving files from the database to three new ones. Is very helped with all the tags I have attached to the files.

Again, thanks! :slight_smile:

2 Likes

Your thoughts and ideas are very understandable and I’m glad to hear you feel good about the path you’re on. :slightly_smiling_face:

1 Like

I believe that was actually the original version of the expression as attributed to Marie Antoinette. It’s been reversed in common English usage and along the way become easier to misunderstand and prone to misapplication.
I also think the original way (ear before have) is clearer somehow.
Also humorous is how replicants are one of the few places where the opposite of the intended meaning actually applies. One can eat the cake, have the cake and keep replicants in multiple groups and not pay the cost of storing multiple copies.

N.B.
I don’t suggest trying to apply the cake metaphor too closely to replicants because you end up in a place with cake that is both eaten and not eaten which is unsavoury by any measure.

3 Likes

According to the Wikipedia entry on the phrase:

An early recording of the phrase is in a letter on 14 March 1538 from Thomas, Duke of Norfolk, to Thomas Cromwell, as “a man can not have his cake and eat his cake”.

So it predates the French queen by some centuries.

2 Likes

That’s fair enough. I wasn’t suggesting your path was wrong, just to be clear. I was just checking you’d thought about your why! Sounds like you’ve got a good system in place, which is really all anyone needs!

3 Likes

“Let them eat cake” is the phrase falsely attributed to Marie Antoinette, but that means something different to “have your cake and eat it”.

For non-English speakers:

“Have your cake and eat it” means you can’t have it both ways (you cannot both enjoy eating the cake and enjoy owning and looking at the cake, the activities are not compatible).

“Let them eat cake” is a phrase that Marie Antoinette didn’t say, and was supposed to be in response to the fact the peasants had no bread to eat (she was the last Queen of France and lack of food was a contributing factor to the French Revolution). Cake (actually brioche) is more expensive to make than bread, so the phrase is used to signal that someone is out of touch with the “common people” and is often used to highlight someone’s privilege or ignorance on a topic (it’s often used to call out a naive position, although someone might use it themselves ironically). If you don’t have the ingredients or funds to make bread, you definitely don’t have the ingredients or funds to make cake.

And finally: here is a periodic reminder that Marie Antoinette was 14 years old when she married and was sent to live in a different country as their soon-to-be monarch. Nearly everything you think you know about her is likely the result of sexism and propaganda, because she was perceived to be an Austrian princess and therefore was an easy target as civil unrest grew.

2 Likes

Since we seem to have the freedom to continue this way-off-topic fork (I apologize, utiPontushage), here, at meaning P.3.a, you can see illustrative uses of the cake saying (not Marie A.'s spurious quote) in the pertinent entry from the Oxford English Dictionary (OED).

I wish the saying had stayed the way it apparently was in 1546, but language is a very slippery thing, and people will say what they’ll say, logic be d**ned.

1 Like