![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 99 Pomógł: 15 Dołączył: 15.11.2007 Skąd: Nowogród Bobrz. Ostrzeżenie: (0%) ![]() ![]() |
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:
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_...)? -------------------- Efemental.pl - nasz punkt słyszenia :: recenzje :: tylko metal!
Opensource'owy klon Cantra: http://github.com/magnax/Simtr |
|
|
![]() |
![]()
Post
#2
|
|
![]() Grupa: Moderatorzy Postów: 36 557 Pomógł: 6315 Dołączył: 27.12.2004 ![]() |
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 -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
![]()
Post
#3
|
|
![]() Grupa: Moderatorzy Postów: 1 566 Pomógł: 37 Dołączył: 14.05.2003 Skąd: Kraków ![]() |
Poziom wyżej niż przedszkole. Przenoszę do MySQL
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 99 Pomógł: 15 Dołączył: 15.11.2007 Skąd: Nowogród Bobrz. Ostrzeżenie: (0%) ![]() ![]() |
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.
-------------------- Efemental.pl - nasz punkt słyszenia :: recenzje :: tylko metal!
Opensource'owy klon Cantra: http://github.com/magnax/Simtr |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 14.08.2025 - 06:37 |