Creating a database driven community

[genoa]

I'm having some design issues.

I'm not quite sure how to tackle a community that is database driven. So far, I have the following flowchart:

main->community_type->community->members

What I need is a way to list the communities, their members and so on. Should I create a database for the community type, with the ID of each community inside it? Then create a database for the community itself?

I could then display all the communities within the type, however I'd have to access each community database (based on ID) to pull their name, and number of members, etc.

Or should I have the community_type database contain the ID, name, and some other info? This would be redundant since I already have it in the community database. Would this save on access times though?

I'm just not sure how to tackle this one. Any ideas?

Any tutorials for database design that don't run off on tangents that don't pertain to what I'm looking for?

My head hurts. I'm not used to having to think in this many dimensions when it comes to database design.



·genoa

If a dog craps in the yard and buries it, is that considered steganography?

 

[sleipnir214]

It seems to me that you have two classes of objects about which you need to record information in your database: members and containers for members.

I would create two tables.

The first table will contain data about the containers. It will have a column with a unique identifier (such as an auto_increment column) and a column which describes the "parent" container of that container.

"Main" would have a parent of zero, denoting that is has no parent. If you create "Main" first, it should then have a unique ID of 1. A community type would then have a parent of 1, and a community in that type would have a parent that is the unique ID of whatever community type in which it falls.

The second table records users. Each user will have a column that describes the community of which he is a member.

If a member can be a member of more than one community at a time, then you'll need a third relating table. This table will have two columns, one that records the unique ID of a community, one that records the unique ID of a member. One row defines a member's single community membership.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!