(Notes from the field: I worked in a place where they didn't know how to normalize... As a result, I was there for 8 months instead of maybe a week. It was Access, but you would run into the same querying problem. About the only thing you can do after the fact is use CROSS APPLY to create a view that returns a normalized result and query that, but why even put yourself through that?)
Spend the time to normalize properly. Your future self will thank you, I promise.
Of course, if you want to learn by "escarmiento" (the hard way), that's good too. Make a dummy database and create both tables. Then write down a bunch of questions you want to answer from the data and try writing the SQL for each. Proof is in the pudding.
I was doing simple data summaries...
1. "what's the severest grade for each symptom for each enrolled patient?"
2. how many are there of each symptom/grade? (Count based on query 1)
If you create the "Reported Symptom" table like this:
CREATE TABLE PatientSymptom (PatientID INT NOT NULL, SymptomID INT NOT NULL, Grade TINYINT NOT NULL...);
and then have a table of Symptoms, like this:
CREATE TABLE SymptomDictionary (SymptomID INT NOT NULL PRIMARY KEY,
Category VARCHAR(255) NOT NULL,
Term VARCHAR(255) NOT NULL,
Grade TINYINT NOT NULL);
then this is a stupid simple query.
Join the two tables, group by PatientID, Category, Term... get MAX(Grade)
then count (wrap that query in another, and just do COUNT(*).
With effectively repeating fields, it gets ugly fast. Requires CROSS APPLY to stack the repeating groups... BLECH.
But since experience is a much better teacher than a lecture, try it yourself. (Seriously, it's absolutely the best way to learn. turn on the timer stuff, (I think it's SET TIME ON), and see how fast your queries are. But remember to clear the cache between tests. (Kevin Kline has some really funny stories about that!).
if you get stuck, post back. But take my word (or better, TRY IT!, learn from objective tests, not someone's opinion!)