database design best practice

[mat]

Hey,

I'm building a site that offers friend list and group features.
The data stored for the friend list and the groups are identical, and
the functionality offered (Permissions on a group by group basis, ie a
user can specify anyone in a certain group can see their post, or anyone
in their friend list can see their post), are identical.

The only real difference is how they are presented to the user, groups
are presented in a management menu, and friends are presented with a
simple "add friend" button.

So my question is; should I make the distinction between the two in the
database, or in the front end.
I figure I could either have one table for both friend lists and groups,
and treat each users friend list as a group, or have two separate tables.

Which would be better semantically/design wise?

Any advice is greatly appreciated.

[Bill Braun]

I suggest a bit of study on relational database design. For
the existance of more than one table (as a broad sweeping
generalization) there ought to be a sound reason for one or
more of these relationships: one to one, one to many, many
to one, or many to many.

If the data in both tables is the same and they are simply
used for different purposes, you might be able to add one
field that distinguishes that difference, and record it in
each record.

Bill B