For all your programming needs

As others have said, you want a clues table.

The clues table needs a question_id column which is obviously a foreign key linking to the id column of the questions table.

Why?

1. You will have only have one clues table, not hundreds
2. You can fetch all the clues for any question really easily by just retrieving all clues from the clues table with a question_id matching the id of your question
3. Other less important stuff, but you can do funky things like automatically delete clues when the associated question is deleted from the questions table (using ON DELETE CASCADE or your dbs equivilant).

Definitely a clues table with an id to a question. The first idea doesn’t really make sense.

The latter. Creating millions of dynamic tables for this use case is not what SQL databases are designed for.

If you create a foreign key relationship from the clues table (column questionID) to the question table (column ID), the database will even guard for you that each clue actually has a valid question associated with it. What's more, if you setup cascading deletes 9n that foreign key relationship, you only need to delete a question row and the clues will automatically be deleted for you. As you can see, this type of relationship is best modeled this way. There are many more reasons why you should do this, but I'm hoping this gives a beginners overview.

You can create one table for all the clues and then do a 1 to n relationship. You create a collumn for the question ID in the clue table. So one question can have more than one clue and each clue knows to which question it belongs.

Unified clue table. It minimises repetition of data and will allow for generalisable queries later on (rather than having to rewrite queries for new questions).

I think trad database design says you should have these tables: Questions Clues Table that only links questions and clues table

Which also means you can reuse clues for different questions too