• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Relational Database Design

ant80

Senior member
I was wondering how to design a database with the following set of requirements.

Problem: It contains a main table of entries (which is the primary key). Some of these entries need to be categorized, some are standalone. So I want to be able to find which ones are related.
Possible Solution: Create a new table with the categories called Categories individually. Create a second table linking the categories in the Categories table, and the serial number in the main table.
Question: Is this the optimal design? Is there any better way to do it?

Problem 2: In the same database as above, there is a different level of grouping that is independent of the categories grouping. However, the name of the grouping is not important. Each group contains upto ten (probably max, but may be higher under rare circumstances) entries from the main table.
Question: How do I go about doing that? I can't seem to think about any solution that doesn't name the groups. Should I just give each group a dummy name and proceed along the lines of the first problem?

Any input would be greatly appreciated. Thanks.
 
Problem 1:
If your categorized data has the same fields as your uncategorized data, then:
MAIN:
PK
FIELD1
FIELD2
CAT_PK (foreign key)

CATEGORIES:
CAT_PK
CATEGORY

If you have more fields for certain categories, you don't want to implement it that way.

I don't really understand the second problem. If you're asking what I think you're asking, just make a new table GROUPS or whatnot.
 
Back
Top