I've noticed that Directory Opus writes user-defined tags and comments to the NTFS file system, which is understandable. However, if this is the only way it's done, it creates a problem: when we need to search for files using tags or comments as query conditions, the search speed is very slow.
I believe the correct approach would be to save this user-defined metadata in a separate, associated database, a JSON file, or a DAT file—in any case, a standalone file. This way, during subsequent searches, we wouldn't need to traverse folders or scan the hard drive, which would dramatically improve search speed.
This is a common, modern file management method, and xyplorer uses it as well. Therefore, I naturally assumed that the official version of Directory Opus would provide such an option. Unfortunately, AI has informed me that the official DO does not offer this setting, and that users need to write their own scripts to save user-defined descriptive data into a separate database.
You can do that in Opus if you use Labels instead of tags, and set labels to be stored in your configuration. (Assuming the tags are known in advance and new ones are only needed occasionally, else the setup side of things would probably be too time consuming.)
Or put the tags in a Description (User Comment) and configure those to be store in descript.ion files rather than NTFS ADS. (That gives one file per folder, which will speed things up for folders with lots of files, but may not make much difference if the files are all in different places.)
A downside to both methods (and any separate database for metadata) is that the metadata won’t go with the file if it’s moved or renamed by something else.
Fwiw, that doesn't sound modern to me. Doing a quick search shows the potential problems with that approach.
I'm not sure how long you've been trying Opus, but in my case I don't see it being slower than searching for other types of data, p.e. stored inside the file?
A more decent approach that xyplorer seems to offer (since its modern approach has a 100mb size limit apparently) would be to use Everything v1.5 and index tags/ratings (accesing even to ADS stored values). Then you can use that index when doing a search in Opus and get instant results.
Additionally, you can also create a command that do exactly that: write a database with values, also being able to search the database, etc.
In fact, we can choose both methods simultaneously. I believe that modern file management should draw more inspiration from the way web servers handle unstructured files on the backend. For instance, some websites may have tens of millions of videos or images, yet they can quickly retrieve any file and flexibly display various sort orders and views. This efficiency is due to putting the file descriptions into a database.
The approach taken by XYplorer is to store file descriptions in an external dat file; whenever a file is modified within XYplorer, the dat file is updated accordingly. Although XYplorer's overall performance may not be outstanding, this method makes XYplorer retrieval extremely efficient.
Even if you store user descriptions in ion files, the fact that these ion files are scattered across multiple folders means that when the software needs to retrieve them, it must traverse through all those folders. On the other hand, if you place user descriptions in a database, it would greatly improve file retrieval performance, flexibility, and maintainability. Imagine this: users could add key-value pairs to their files, and at some point in the future, filter and sort based on those key-value pairs—doesn't that sound more appealing than the original method?
That would be great !!! And it would also break as soon as any piece of software (XYplorer, File Explorer, any other software) moves any file around since this will be done outside of the software that maintains that database.
This is pure nonsense ... unless that database is handled by the underlying file system.
If you want the tags stored in a database, several ways to get that have already been suggested above.
It sounds like you want to use a search index, in which case Everything is the thing to use, and described by Errante above. (Windows Search is another option, but I would always pick Everything over that. Both of their search indexes can be queried from within Opus.)
You wouldn't really want to use "both ways simultaneously" (if by that you mean storing the same data in both NTFS ADS and a separate database) because then the tags would get out of sync between the two storage systems and it would become a mess which combined the worst of both methods.
I'd also be surprised if using descript.ion files was slow in most situations. Reading one file per directory usually won't cost much time.
I'm not sure what relevance web servers have here. They're completely different to file managers. Web servers also do not have file descriptions for every file as standard, and don't usually have to deal with other software moving/renaming files underneath them.