Database Design – Determining Functional Dependencies from Tuples

I concur with your speculation that it's bad design practice. I'd recommend against it. Any time you do this sort of thing, it almost inevitably comes back to bite and the performance difference compared to a properly designed schema should be small.

You say that as it stands now, your process "would involve searching through the first table for all question_ids answered by the user, then searching the topics_and_questions table" but that's not really a good analysis of what should happen behind the scenes.

Properly designed, this process would involve checking an index on the first table for all questions answered by the user, joining to the second table to find the topics of the questions (and possibly a third table to find the names of the topics), but all in one query and with no full table scans.

If your first table (no table name provided) has (user_id, question_id) as its primary key (as it probably should), then finding the questions answered by each user will be a fast operation, no matter how many records are in this table. Rows in InnoDB are stored in primary key order, so there's no "searching though" the entire table that needs to happen... the storage engine can go directly to where that user's records are without a full table scan. If (user_id,question_id) isn't the primary key, then adding an index on (user_id,question_id) will optimize this part of the query.

In topics_and_questions either (question_id) or (question_id,topic_id) should probably be the primary key, depending on whether a question can be in multiple topics. If it can, of course, then counting questions answered becomes more complicated.

Since you appear to be allowing a user to answer the same question more than once, there may be yet another issue to consider: you actually have to duplicate part of what you're trying to avoid, every time you update this new proposed table: You have to check whether the question just answered was one that's been answered before, or not, and only increment this counter, if it is, I would assume.

2NF: Remove Partial Dependencies

R = {A, B, C, D, E, F, G, H, I, J} includes partial dependencies.

D and E depend only on A, F depends only on B, G, H, I and J don't depend on the key (directly) at all.

R0 = {A, B, C}

R1 = {A, D, E, I, J}

R2 = {B, F, G, H}

R0, R1, and R2 contain no partial dependencies (or repeating groups) so they are 2NF. However R1 and R2 are still an issue, because they contain transitive dependencies.

3NF: Remove Transitive Dependencies

I and J depend on D, not on the key of R1. Therefore you need to further normalize R1 as follows:

R1 = {A, D, E, I, J}

R1a = {A, D, E}

R1b = {D, I, J}

Similarly, G and H depend only on F so R2 must be decomposed as follows:

R2 = {B, F, G, H}

R2a = {B, F}

R2b = {F, G, H}

Now all of your remaining relations (R0, R1a, R1b, R2a, R2b) are devoid of repeating groups, partial dependencies and transitive dependencies. That means your relations are in 3NF.

When you are looking at an relation that hasn't been normalized and a series of dependencies, you can often normalize by inspection just by recognizing what your primary keys are going to be. Any attribute or combination of attributes that functionally determine other attributes are going to end up as primary keys. Once you've got your primary keys defined, you just need to figure out which non-key attributes go with each key. This is obvious from the statement of what your functional dependencies are.