Re: CUG

On Sun, 4 Feb 2001, Nabil Sayegh wrote:

> Okay, this could be an option, perhaps it's best to implement several
> different
> mechanisms from which the customer may choose.

I highly recommend to pick a method and stick to it. I continue to think
that you are trying to use canons to kill mosquitos. In other words that
you are over designing this. Again maybe I don't really understand what
you are trying to do, but what you describe as your needs and what you
describe as your solutions seem to have a very big gap between what is
needed and what you are trying to implement.


> That's the state of affairs. Now I want to attach group girlfriend(s) to
> group friends so that if I add new pictures and give them the group friends my girl
> may see it,
> !!!without_explicitly_mentioning!!!

This makes 0 sense to me. If you want your girlfriend to see the pictures
that friends can see, add her to the friend group.

> I would like to add another table group_group and this puzzles me
> because I would need to recurse.

I still don't see what recursion would get you except tons of more chances
to screw up the design, lengthen development and increase chances of
having to scrap the whole thing and do it from scratch at a later date.


> Perhaps It could be done transparent to the customer by adding triggers
> which automatically add a new user to all necessary groups via

Again... my suggestion is:
-A picture can be specified to be seen by different groups.
-Put whoever you want to see the picture in the appropriate group(s)

If you want all member of Group A to see the same pictures that Group B
can see simply select the ID of all pictures visible by Group G and create
records for Group A to be able to see the same pictures.