2 added 319 characters in body
source | link

It might not be the most elegant model - but your description points to 2 (independent) m:n relations between Clients and Accessories and Employees and Accessories. The usual way to resolve those m:n relations IS to create mapping tables like you did - so nothing wrong from that view point. Of course it needs joins to request data over the 3 tables, when you want to know what accessories are still held by a certain Client or employee.

If your clients or employees receive the same initial sets of accessories you can go like @Akina wrote in the comments. Fill a small template table with the sets you want to give new clients / employees and copy the lines over - while filling in the correct clientID / employeeID to the corresponding mapping table.

It might not be the most elegant model - but your description points to 2 (independent) m:n relations between Clients and Accessories and Employees and Accessories. The usual way to resolve those m:n relations IS to create mapping tables like you did - so nothing wrong from that view point. Of course it needs joins to request data over the 3 tables, when you want to know what accessories are still held by a certain Client or employee.

It might not be the most elegant model - but your description points to 2 (independent) m:n relations between Clients and Accessories and Employees and Accessories. The usual way to resolve those m:n relations IS to create mapping tables like you did - so nothing wrong from that view point. Of course it needs joins to request data over the 3 tables, when you want to know what accessories are still held by a certain Client or employee.

If your clients or employees receive the same initial sets of accessories you can go like @Akina wrote in the comments. Fill a small template table with the sets you want to give new clients / employees and copy the lines over - while filling in the correct clientID / employeeID to the corresponding mapping table.

1
source | link

It might not be the most elegant model - but your description points to 2 (independent) m:n relations between Clients and Accessories and Employees and Accessories. The usual way to resolve those m:n relations IS to create mapping tables like you did - so nothing wrong from that view point. Of course it needs joins to request data over the 3 tables, when you want to know what accessories are still held by a certain Client or employee.