Hello,
how do I get rid of the multiple tags?
Some tags appear four to five times in my tag list, depending on which databases the corresponding documents are stored in.
Can I summarize the tags so that they are only displayed once (and edited or deleted once?)
No. They are in different databases, but I would like to have them all in a list where all my tags appear only once so I can rename or delete them easily.
The tags of each database should be unique 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.
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.
Hi, Jim.
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.
For example:
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