Question

A user can be in groups. And an item/product is assigned groups that can see the item. Users can see that item if they are in one of the assigned groups.

I want neither public (anonymous users in no groups) nor groupless users (logged in users not in any groups) to see the item. But I want the interface to allow assigning the item an ‘all/any groups’ attribute so that users that are in any group at all can see the item.

Where/How should I store this assignment?

p.s. I expect the technique to also be extended to other entities, for example I’d assign a file to a category, and groups are linked to categories. so when a file is marked as visible by the ‘all/any category’ then if the user (thru groups and group-categories) is linked to at least one category then the file is visible to them.

Decision:

It seemed the choice was whether to implement as a row in a entity-groups table or as fields in the entity table. The chosen answer used the former.

And either managing the group membership in a table or adding JOIN conditions. The chosen answer used the former, but I’m going to use the latter. I’m putting an indirection between the query and usage so if (when) performance is a problem I should be able to change to a managed table underneath (as suggested) without changing usage.

I’ve other special groups like ‘admin’, ‘users’, etc. which can also fit into the same concept (the basis simply being a list of groups) more easily than special and variable field handling for each entity.

thanks all.

Answer 1

As mentioned by both Martin Smith and Mikael Eriksson, making this a property of the entity is a very tidy and straight forward approach. Purely in terms of data representation, this has a very nice feel to it.

I would, however, also consider the queries that you are likely to make against the data. For example, based on your description, you seem most likely to have queries that start with a single user, find the groups they are a member of, and then find the entities they are associated to. Possibly something lke this…

SELECT DISTINCT -- If both user and entity relate to multiple groups, de-dupe them
  entity.*
FROM
  user
INNER JOIN
  user_link_group
    ON user.id = user_link_group.user_id
INNER JOIN
  group_link_entity
    ON group_link_entity.group_id = user_link_group.group_id
INNER JOIN
  entity
    ON entity.id = group_link_entity.entity_id
WHERE
  user.id = @user_id

If you were to use this format, and the idea of a property in the entity table, you would need something much less elegant, and I think the following UNION approach is possibly the most efficient…

<ORIGINAL QUERY>

UNION       -- Not UNION ALL, as the next query may duplicate results from above

SELECT
  entity.*
FROM
  entity
WHERE
  EXISTS (SELECT * FROM user_link_group WHERE user_id = @user_id)
  AND isVisibleToAllGroups != 0

-- NOTE: This also implies the need for an additional index on [isVisibleToAllGroups]

Rather than create the corner case in the “what entity can I see” query, it is instead an option to create the corner case in the maintenance of the link tables…

1. Create a GLOBAL group
2. If an enitity is visible to all groups, map them to the GLOBAL group
3. If a user is added to a group, ensure they are also linked to the GLOBAL group
4. If a user is removed from all groups, ensure they are also removed from the GLOBAL group

In this way, the original simple query works without modification. This means that no UNION is needed, with it’s overhead of sorting and de-duplication, and neither is the INDEX on isVisibleToAllGroups needed. Instead, the overhead is moved to maintaining which groups a user is linked to; a one time overhead instead.

This assumes that the question “what entities can I see” is more common than changing groups. It also adds a behaviour that is defined by the DATA and not by the SCHEMA, which necessitates good documentation and understanding. As such, I do see this as a powerful type of optimisation, but I also see it as a trades-and-balances type of compromise that needs accounting for in the database design.