Database Design For Course Registration & Pricing - sql

Question

How would you design the table(s) to handle a registration form and pricing for an upcoming event?
As seen in the table below:
+-----------------------------+-------------------+----------------+--------------+
| Occupation/Level | Optional Item | Base Price | Early Bird Price |
+-----------------------------+-------------------+------------+------------------+
| Residents | | $1000 | $800 |
+--------------------------------------------------------------+------------------+
| Practitioners | Exam Prep (+$500) | $1500 | $1300 |
+--------------------------------------------------------------+------------------+
| OBYGN Consultant - Friday | | $800 | $900 |
| OBYGN Consultant - Saturday | | $800 | $900 |
| OBYGN Consultant - Sunday | | $600 | $700 |
| OBYGN Consultant - All Days | | $1900 | $2100 |
+-----------------------------+-------------------+------------+------------------+
different prices are charged based on the attendee's occupation.
practitioners have access to an optional exam preparation session for an additional fee
OBGYN Consultants have the option of registering for single/multiple days; each of which charges a different amount
To further illustrate the details, here's a screenshot of the old registration form.
My initial idea is to keep it very simple and treat each line separately and store the amount with it. The days which an OBGYN Consultant may choose simply become another line in the table.
+----+---------------------------+----------------+------------------+
| ID | Occupation/Level | Base Price | Early Bird Price |
+----+---------------------------+----------------+------------------+
| 1 | Residents | $1000 | $800 |
| 2 | Practitioners | $1500 | $1300 |
| 4 | OBYGN_Consultant_Friday | $800 | $900 |
| 5 | OBYGN_Consultant_Saturday | $800 | $900 |
| 6 | OBYGN_Consultant_Sunday | $600 | $700 |
| 7 | OBYGN_Consultant_All_Days | $1900 | $2100 |
+----+---------------------------+----------------+------------------+
The optional_materials table would handle any courses that have additional options.
+----+----------+-----------+--------+
| ID | CourseID | Name | Amount |
+----+----------+-----------+--------+
| 1 | 2 | Exam Prep | $500 |
+----+----------+-----------+--------+
See any major issues with this design OR see a better way of handling it?

Answer 1

Depends on how flexible you want to be in the future. If you for example want to have a super early bird price next year or you will support different currencies then I would make it like this:
+----+----------+---------------------------+------------+-------+----------+
| ID | CourseID | Title | Price Type | Price | Currency |
+----+----------+---------------------------+------------+-------+----------+
| 1 | 1 | Residents | Base | 1000 | Dollar |
| 2 | 1 | Residents | Early | 800 | Dollar |
| 3 | 2 | Practitioners | Base | 1500 | Dollar |
| 4 | 2 | Practitioners | Early | 1300 | Dollar |
| 5 | 4 | OBYGN_Consultant_Friday | Base | 800 | Dollar |
| 6 | 4 | OBYGN_Consultant_Friday | Early | 900 | Dollar |
| 7 | 5 | OBYGN_Consultant_Saturday | Base | 800 | Dollar |
| 8 | 5 | OBYGN_Consultant_Saturday | Early | 900 | Dollar |
| 9 | 6 | OBYGN_Consultant_Sunday | Base | 600 | Dollar |
| 10 | 6 | OBYGN_Consultant_Sunday | Early | 700 | Dollar |
| 11 | 7 | OBYGN_Consultant_All_Days | Base | 1900 | Dollar |
| 12 | 7 | OBYGN_Consultant_All_Days | Early | 2100 | Dollar |
+----+----------+---------------------------+------------+-------+----------+
But overall your approach is totally valid.
Also concider adding a "Created" and "Edited" date field in the end. Makes it easier to keep transparency over data changes (maybe you want to highlight options that are only available or have changed over last 14 days or so)