Pomagam znajomemu zaprojektować grę, a konkretniej bazę danych do gry.
Wydzieliliśmy sobie następujące encje do osobnych tabel:
- lokacja (miejsce na mapie),
- budynek (związany z lokacją),
- przedmiot (dowolny, np. szabla, krzesło..., ważne że policzalny),
- zasób (piasek, mięso... niepoliczalny),

Następnie jako odrębna encja nasuwa się:
- projekt (jakaś czynność trwająca pewien czas, np. wytworzenie szabli w odróżnieniu od natychmiastowego podniesienia szabli).

Każdy projekt będzie miał jednakowe atrybuty typu czas rozpoczęcia, czas trwania, właściciel (rozpoczynający) itd. Ale projekty dzielą się na:
- podróż do innej lokacji,
- postawienie budynku,
- wyprodukowanie przedmiotu,
- wydobycie lub przetworzenie zasobu.

Jak widać docelowym produktem tych projektów jest jedna z 4 różnych encji (jednym z parametrów projektu jest zawsze bieżąca lokacja, więc w przypadku podróży wystarczy dodać tą docelową).

I teraz mam dylemat jak to poprawnie zapisać w jednej tabeli... a może jednak nie w jednej a jakoś inaczej.
Czy będzie prawidłowa taka konstrukcja tabel:

[SQL] pobierz, plaintext 
Lokacja
----------------------------
| id | nazwa | inne pola |
----------------------------
 
Budynek
----------------------------
| id | nazwa | inne pola |
----------------------------
 
Przedmiot:
----------------------------
| id | nazwa | inne pola |
----------------------------
 
Zasób:
----------------------------
| id | nazwa | inne pola |
----------------------------
 
Projekt:
----------------------------------------------------------------------------------------
| id | nazwa | id_lokacja | id_budynek | id_przedmiot | id_zasób | inne pola |
----------------------------------------------------------------------------------------
[SQL] pobierz, plaintext 

czyli 4 klucze obce, z których 3 będą jako NULL a czwarty będzie wskazywał odpowiedni rekord z odpowiedniej tabeli?

Można wtedy mieć wszystkie projekty "w kupie" w jednej tabeli (zaleta przy np. aktualizacji postępu wszystkich projektów - jedno zapytanie).
Czy może lepiej jednak zrobić osobną tabelę na każdy typ projektu (projekt_podróż, projekt_budowa, projekt_...)?

tak jak jest wydaje mi się ok.

Możesz też pokusić się o taki model:

Projekt:
----------------------------------------------------------------------------------------
| id | nazwa | typ | id_typ

gdzie typ to jakas liczba okreslająca czy to budynek, lokalizacja, itd, a id_typ to id rekordu z tabeli odpowiadającej dla danego typu.
Wada tego rozwiązania to to, ze nie uworzyć w bazie klucza obcego dla id_typ, gdyż id_typ moze wskazywać na 4 rozne tabele

Poziom wyżej niż przedszkole. Przenoszę do MySQL

nospor: tak na początku kombinowałem, ale właśnie brak możliwości utworzenia klucza obcego mnie przekonał, że to nie jest dobre rozwiązanie.