In order to let the user create arbitrary groups for entities in the system, we can implement a tags system that they can then use to work with their mental model of their songwriting system. This covers the bases for things like "favorites" or "folders". Let the user decide what is important to them and how they want to think about their workspace.
Tags need to scale and be searchable, so I think from the start they should not live on objects, and instead be in a separate table and point to objects.
Pseudo SQL:
create table tags
column id
column name
column user_id
column project_id
column entity_type
column entity_id
Then a user can easily tag things and group them into their own arbitrary systems. When viewing tags, you should be able to filter on entity type and by project, but also browse globally.
Being able to see something like "this tag is tagged on 10 entities in all of your projects" would be useful and efficient to calculate in this system.
I originally was thinking we would have separate tags and taggings tables to de-duplicate things, but I actually don't think we need the separate tags table. We just need to be be able to present it to the user like that. "Which tags have they used recently?" I started questioning this is because is it the user_id column on the tags table seems off. The user owns the idea of that tag? I converged with "The usage of the tag associated with a project for access control, and is done by action by the user".
A tag's name is obviously not a unique id for that "tag". But tags can be queried from the database in different ways based on their user_id and project_id, to make it seem namespaced to the current user.
In order to let the user create arbitrary groups for entities in the system, we can implement a tags system that they can then use to work with their mental model of their songwriting system. This covers the bases for things like "favorites" or "folders". Let the user decide what is important to them and how they want to think about their workspace.
Tags need to scale and be searchable, so I think from the start they should not live on objects, and instead be in a separate table and point to objects.
Pseudo SQL:
Then a user can easily tag things and group them into their own arbitrary systems. When viewing tags, you should be able to filter on entity type and by project, but also browse globally.
Being able to see something like "this tag is tagged on 10 entities in all of your projects" would be useful and efficient to calculate in this system.
I originally was thinking we would have separate
tags
andtaggings
tables to de-duplicate things, but I actually don't think we need the separatetags
table. We just need to be be able to present it to the user like that. "Which tags have they used recently?" I started questioning this is because is it theuser_id
column on thetags
table seems off. The user owns the idea of that tag? I converged with "The usage of the tag associated with a project for access control, and is done by action by the user".A tag's name is obviously not a unique id for that "tag". But tags can be queried from the database in different ways based on their
user_id
andproject_id
, to make it seem namespaced to the current user.