ogólna tabelka

Hej,

Projekt jaki robię w domu jest aplikacją do nauki. W skład jego wchodzi kilka różnych zadań. Dla każdego typu zadań mam w bazie tabelkę z ćwiczeniami i odpowiedziami.

O ile zarządzanie tylko jednym typem zadań jest proste to niezbyt czuje jak powiniem zarządzać wszystkimi zadaniami tak, by była np. możliwość oznaczania ulubionych zadań, zadań na trening, listowania wszystkich zadań względem kategorii, czy też czasu utworzenia.

Wydaje mi się, że najrozsądniejszym wyjściem jest utworzenie ogólnej tabelki Quest, która ma jakiś generyczny uchwyt do zadania na jakie wskazuje.

Jaki waszym zadaniem jest najrozsądniejszy sposób zarządzania danymi w tym przypadku?

Quests
Id (int) PK
CreationTime (date)
Question (string)
AnswerId (int) FK, lub od razu poprawna odpowiedź bez dodatkowej tabelki
Favorite (bool)
ToTraining (bool)
CategoryId (int) FK na Categories

Categories
Id (int) PK
Name (string)

Answers
Id (int) PK
Answer (string)

lub jeśli może być wiele odpowiedzi do jednego pytania czy też odpowiedzi typu A B C wtedy:

Anserws
Id (int) PK
Answer (string)
QuestId (int) FK na QuestId z Quests i kolumna AnswerId w Quests nie potrzebna
IsCorrect (bool)

Zaznaczam tylko że sam niedawno zacząłem wykorzystywać SQL więc mogłem to wymyślić źle.

Dzięki @dam1an, ale twoja odpowiedź zakłada, że operuję tylko jednym typem zadań.

Niestety, w moim przypadku poza zwykłymi zadaniami w stylu A, B, C, D mam jeszcze zadania uzupełnianiem luk w tekście, układaniem rozsypanego tekstu (puzzle), i różne kombinacje zadań z podręczników.

To jak dotąd to trzymałeś?
Do Answers możesz jeszcze dodać TypeId z FK do nowej tabeli Type Gdzie będą przetrzymywane te typy zadań i będziesz wiedział wtedy jak to wyświetlić w programie.

To jak dotąd to trzymałeś?

Nie trzymałem, starałem się unikać tego tematu, ponieważ nie mam na niego pomysłu. Teraz jednak nie mogę tego przekładać i muszę rozwiązać to tak, bym za miesiąc nie musiał tego zmieniać.

Mając TypeId treść pytania i odpowiedzi sprowadzi się do postaci tekstowej takiej jak json bądź hstore. Wówczas stracę schemat i wiele korzyści jakie oferuje mi baza. Poza tym ze strony samego kodu tracę kilka fajnych ugodnień jak np. automatycznie wygenerowane formularze na podstawie modelu.