In past projects, where we needed to group records, like users into groups, the traditional method was a has_and_belongs_to_many structure.

You would create a group, assign users as members of the group.

So Web 1.0, right?

In a recent project for managing e-mail, I experimented with loose relationships. We only looked up contacts when viewing a message. Never actually hard linking the message to a contact_id.

It was a great success, with contacts and messages managed independently, yet still providing relevancy to the content as users added new data to either entity.

On a new project, once again I am implementing group functionality. This time I am trying to use tags instead. Dangling them off the lowest leaf in the structure, the client, instead of as a parent or peer.

My hope is that this will simplify the creation of groups, and provide a simpler UI experience for the users.

A lot of people talk about UI design, but there are few examples of actual implementations.

What is the best way to manage habtm or has_one with 10,000 choices?

It would be nice if there was a site where the best practices are posted for discussion and reference.