but the unified tags section does not yet merge tags located in multiple databases and having the same name. However, this is planned for future releases.
I would disagree with this.
Databases are independent entities. Their Tags are also independent entitites, hence they can and should be presented more than once. Selecting the top level Tags group will display redundant Tags, but they aren’t actually redundant in the context of the independent databases.
I didn’t really understand why every database has to have its own tags. For me, it would be much more logical if the tags were related to the note or file, no matter what database it’s in.
I’m importing a file. It ends up in “Eingang” (is that “Input” in the international version of DT?), where I tag it. (= one tag in “Input”).
Then I move it to the database “A” (= one tag in “Input”, one tag in “A”).
Damn! Wrong database! This file should actually be in database “B”. I move it to “B” (= one tag in “Input”, one tag in “A”, one tag in “B”).
(You remember that we are still talking about one single file.)
Now I remember that I could also use the file in database “C”. So I replicate it in “C” (= one tag in “Input”, one tag in “A”. one tag in “B”, one tag in “C”).
And now I want to change the tag. Then I have four times the same one in front of me. What if I want to clean up my tag list (which I do from time to time)? Then it is very long and confusing.
If every database has to have its own tags, wouldn’t it be possible to create separate view, a table in which the tag is listed only once and in a second column the corresponding files and the databases in which they are stored? And changes to this one tag apply to all databases?
Databases are separate entities though you can construct ones that have logically connected (or even redundant) information in them. All your separate databases do not constitute a singular body of work, except perhaps conceptually.
Databases are not merely groups of data. They are more akin to books. If you have two books about whale watching (and who doesn’t! ), each book will have its own glossary of terms even though many of the words would be the same. If you wanted to use one set of terms, it would be better to create a compendium, a massive volume of whale watching information, with one set of words in the glossary.
Per this analogy, yes it is possible to create a larger database with one set of tags. And if you had a ton of related information, I would suggest keeping those things in one database.
What if I want to clean up my tag list (which I do from time to time)? Then it is very long and confusing.
You could use @cgrunenberg’s smart rule to clean out empty tags. Let me look for it, in case he doesn’t chime in…
But seriously: you don’t really want to compare databases connected in a complex database system with books on a shelf.
Sure I do. Don’t look at the technology as being inherently complex. This is a mistake people fall into and think DEVONthink’s mythical “learning curve” is so steep. DEVONthink can be used incredibly simply or in complicated ways. The experience is dictated to a large part by what the user brings to the table.
I have a variety of databases that suit my needs and wants. Some of it may make no sense to you, and some of what you’re doing would likely confuse me. But that’s part of the beauty of DEVONthink. It’s NOT just for business, or academia, etc. (Now you got me preaching - which you’ll also see in the Help > Documentation > Getting Started chapter. ).
PS: Yes, books smell and feel better. But databases don’t have a 100% advantage for sure. My books never run out of battery power or hav to be upgraded every so often.
Don’t look at the technology as being inherently complex.
I never did.
This is a mistake people fall into and think DEVONthink’s mythical “learning curve” is so steep.
I’ve never complained about DT*s learning curve. I use DT almost from its beginning. In the beginning it was a very simple but also very helpful system. Of course it was further developed and more and more functions and possibilities were added. Since I was satisfied with my way of working with DT, I didn’t get all the new features.
I guess nobody uses all the features of an app, especially if it’s as powerful as DT. And soon I will have the time to read the documentation in detail and try out aspects I don’t know yet.
But databases don’t have a 100% advantage for sure. My books never run out of battery power or hav to be upgraded every so often.
But you need a lamp if you want to read at night, you need several rooms where others only need a connection to the cloud and you cannot upgrade books
Don’t get upset now. I love books as well.
@BLUEFROG ok, so what is the solution you propose then? Say i have 8 databases and all have a tag named ‘basketball’ in them. If you don’t union/merge the tag in a view, how do you make them unique when viewing? ‘databasename-basketball’ will blow up very quickly.
Was going crazy trying to organize TAGS until I read this string, then I added a “Location” column to the TAGS view. Now I can sort and see what TAGS are specific to each database and merge identical TAGS in the same db.
Still, I would like to have a unified TAGS method (though I understand why they are separate now). For example I have an article discussing Amazon and Facial Recognition. I have one db for Corporations and another db for Emerging Technology. If I place the article in the Corporations db and add a TAG Facial Recognition it will be a separate and redundant tag to the Facial Recognition TAG found in the Emerging Technology db. Would be nice to have one TAG to group everything regardless of the db. Of course that probably falls in the ‘easier said than done’ category.
Search does a good job of being the unifier between dbs.
Excuse me, A small question~
Is there an upper limit on the storage capacity of the database? One of my databases is nearly 200G now, I am a little worried that the growth of data will bring stability risks. I am considering whether to split the database, this will indeed produce different databases but the same tag system problem