This multitude of tags

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?)

1 Like

Are the tags in the same database? Then you should be able to select them and merge them afterwards via the contextual menu.

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.

1 Like

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.

Just IMHO.

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?

Translated with www.DeepL.com/Translator

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! :stuck_out_tongue: ), 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ā€¦

https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/2X/7/793544bd1df66ba6c711fd38116311f78922bd74.png

From:

4 Likes

Hi, Jim.
Youā€™re right, I have a lot of books on whales. I checked - they all have a glossary.

But seriously: you donā€™t really want to compare databases connected in a complex database system with books on a shelf.

Itā€™s true, books smell better than databases, but you wonā€™t deny that databases have technological and systematic advantages over books.

Tagging book entries would make no sense at all.

Thank you for referring to the @cgrunenbergā€™s smart rule. Where can I download it? I would like to see if this helps me.

Oops! Sorry, Jim. You sent me a smart rule. I just realized that! Of course I can set it up myself. Pfff!

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. :slight_smile: ).

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. :stuck_out_tongue:

1 Like

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 :wink:
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.

1 Like

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 :thinking:

Seeā€¦

Thank you~

Youā€™re welcome.

So I have a db with 564,343 unique and 41,175,900 total words. (64GB RAM). Should I be worried? Should I be considering splitting this database?

You arenā€™t near the comfortable limit but you are more than welcome to split any database.

This simple change really helps! Good tip.