There’s currently no way to do that. What people do is simply dump the database into a temporary file and include that in the backup run. Can’t you do that?
We just live with separate backups (tagged appropriately, and we use forget --group-by host,tags). There aren’t really any downsides to this approach. It’s pretty rare that you would restore the whole thing in one go. Usually you’d restore the system backup, get the DB service operating again, then import the database dump. Since a two-phase restore is usually required, it doesn’t help much to restore a system+DB snapshot.
Plus you can use restic dump ... | gunzip | mysql to restore without needing temporary files on restore, as well, so you’d need two operations to restore anyway (restore + dump). Putting everything into one snapshot requires that you have enough free disk space to store an entire dump on the DB server.
Having a single snapshot for system+DB just isn’t worth the hassle, IMO.
You can tag them however you want, but I would recommend you use simple tags instead of a novel like description of what you’re backing up. Perhaps system-<yymmddHH> and db-<yymmddHH> or similar (depending on how often you run the backup)? You don’t really need the dates in there as you will have the dates in the snapshot info anyway. Think about how you’d go about restoring, and you’ll find a tagging strategy that is useful.
I use the tags system and database. I’m not sure why you’d need or want the date in the tag; that seems silly. The snapshot already contains the date and time it was taken. If you take backups daily then you can correlate the two snapshots based on the date in the snapshot.