Entire Table Stored in Indexes

I have a question that involves database design. For an application that I am building, a certain set of unique identifiers needs to be related to a variable amount of data. The solution that I built involves two tables.开发者_开发百科

The first table has an auto incrementing primary key ID, along with two columns that are both in a unique index (which work to identify the specific set of data). The second table then references the primary key, and stores data along with this key.

Using this technique, I am able to link the two identifiers that are contained in the unique index in the first table with a variable amount of rows in the second table.

I know that this will work, but my question involves the viability of this structure. Is it poor database design to have the entire first table contained in indexes? Can anyone think of any better solution that does not involve duplicating the identifiers used in the first table?

I am using MySQL along with innodb, if it is pertinent to the question.

Is it poor database design to have the entire first table contained in indexes?

Not in your case. The real question should probably be, "What are the candidate keys in the second table?"

In your case, you can think of your "first" table as an enumeration of the valid values implied in a hypothetical CHECK() constraint.

Have you ever heard of domain-key normal form (DKNF)? The more familiar 3NF, BCNF, 4NF, and 5NF are special cases of DKNF.