Out of the box, Helium supports a few multi-valued fields such as artist or label. On those fields, the advanced tag editor shows a three dots button for easy edition.
As a classical music tagger, I would really appreciate the same feature for a small number of other fields, such as composer or orchestra, as well as several of my custom fields.
Would it be possible to add a way to enable multiple values on a field basis, including custom ones ?
It is generally not a problem to add multi-value support to just tag-fields, the problem and complexity comes when the database should support multiple values per-field instead of just one field.
This also have a negative effect of perforance.
Hi Mikael and thanks for answering so quickly!
It would be interesting to measure that impact. From my point of view, it would definitely be worth trading a few milliseconds for improved library management.
As far as I understand, allowing multiple values in a single field wouldn't require adding costly SQL operations such as JOIN etc. This would only result in a few more records in a table. Or am I wrong?
If you only need to store multiple values in a field it won't involve multiple JOIN operations, but that will also limit the possibilities with searching and filtering.
-There can be multiple artists for a track in Helium, 1-n artists is supported
-To be able to perform exact searches an extra mapping table (cross-table) is needed between a track and an actual artist.
-This will give the possibility to find tracks from a specific artist, using complex filtering, statistics and such, BUT, it will require an additional table thus an extra join.
The cost for this is unfortunatley more than a couple of milliseconds.
I understand. SQL Server has indexed views to improve performance in such cases, but AFAIK they do not exist as-is on MariaDB, which is a problem as you support several DB engines.
I'll manage and deal with it another way. Thanks for taking some time to answer though!
You are welcome.
MySql/MariaDB create indexes by default, but for database types such as Sql Server Compact, our default type, it doesn't help much in creating indexes when the databases contains "quite much" data, since it's a little too slow for that.
I'm also insterested by this request. It's very important for all fields that are similar to the artist field.