MySQL - Struktura bazy danych

Witam!
Tworze baze danych dla ponizszego schematu:

• zbior projektow,
• A projekt (ma wiele tematow),
• B tematy (maja wiele zadan),
• C zadania (maja wiele dzialan)...

Zastanawiam sie jak stworzyc najbardziej wydajna strukture.
Jedyna rzecz ktora przychodzi mi do glowy to utworzenie odrebnej tablicy dla kazdego elementu tzn. kazdy projekt to osobna tabela np. A1 w ktorej sa adresy kolejnych tabel B1, B2, B3 (dokladnie A1B1, A1B2...) w ktorych znow sa adresy kolejnych tabel (np. do B1 jest C1, C2, C3...). Wszystkie elementy maja niepowtarzalne klucze ale tylko w zakresie tabeli parent czyli np C1 moze wystepowac zarowno w B1 jak B2 jak B3 (z rozna wartoscia ale tym samym kluczem)....

Rozwiazanie to jest troche skomplikowane poniewaz tworzy ogromna liczbe tabel.... W zwiazku z tym mam pytanie. Czy ktos ma moze jakis inny pomysl, a takze czy tworzenie duzej ilosci tabel nie spowalnia dzialania bazy danych.
Dzieki za wskazowki.

yyyy, albo tak namieszałeś albo ja źle zrozumiałem ale to jest przeca najnormalniejeszy schemat master detail, tzn

projekty
*projekt_id
...

tematy
*temat_id
#projekt_id
...

zadania
*zadanie_id
#temat_id
...

dzialania
*dzialanie_id
#zadanie_id

Dzieki za odpowiedz MisiekD.
Zapewne jest to ten master-detail schemat. Nie mam zbyt duzych podstaw teoretycznych.
Problem pojawia mi sie tylko w momencie w ktorym chcialbym nadac ten sam ID np. dla zadania (Z1) w dwoch roznych tematach (T1, T2 ... ).
Wtedy jesli utworze sobie tablice zadania to jak umieszcze tam element
id: Z1, id_temat: T1,
a potem bede chcial wpisac kolejny
id: Z1, id_temat: T2,
to wartosc nie zostanie przyjeta, poniewaz Z1 w tablicy zadania juz figuruje. Mozna by bylo oczywiscie usunac klucz z id i na piechote sprawdzic wszystkie elementy z id_temat=T2, czy wystapil juz id=Z1, ale to troche manualne. Na razie decyduje sie na utworzenie dla kazdego projektu osobnych tabel: projektid_tematy, projektid_zadania, projektid_dzialania... Jak myslicie, czy jest to dobre rozwiazanie?

Nie, to nie jest dobre rozwiazanie. Misiekd podal Ci schemat 1-do-wiele, bo tak napisales w pierwszym watku. Jesli natomiast wystepuje sytuacja wiele-do-wiele (tematy maja wiele zadan, zadania maja przypisane wiele tematow) to utworz tabele laczaca, przykladowo:
tematy
*temat_id

zadania
*zadanie_id

tematy_zadania
*temat_id
*zadanie_id

I caly problem rozwiazany. Rozbijanie elementow jednej klasy (projektA i projektB to ta sama klasa problemu) jest BARDZO zlym pomyslem. Bedziesz tworzyl nowa tabele za kazdym razem? Jak wyobrazasz sobie odpowiednik klucza, indeksu, wyszukiwanie projektow, itp? No i o wydajnosci to nie ma co wspominac.

Możesz zawsze założyć klucz na parę wartości, wtedy unikalna musi byc para a nie pojedyncza wartosc.

Dzieki Jonny i Nav.

Rezygnuje wiec z zakladania kolejnych baz a wszystko zamieszcze w osobnych tabelach: projekty, tematy, zadania, dzialania.
Najbardziej balem sie tutaj zapelnienia tablicy "dzialania", jako, ze bedzie zabierala najwieksza liczbe wpisow, ale gdzies wyczytalem, ze przy umiarkowanej ilosci danych w tablicy moze byc i biliard wierszy, a ja przy jednym projekcie bede mial co najwyzej tylko 1000.

Pomysl z kluczem na dwie wartosci tez jest super. Nie wiedzialem ze do PRIMARY KEY () mozna wpisac dwie wartosci. Super!

Korzystajac z okazji mam jeszcze zapytanie, czy o tej wielkosci to sie dobrze doczytalem...

Wyjaśnij co znaczy biliard. Biliard=1000 bilionów, ale bilion ma różne znaczenie w różnych krajach (10¹² Polska, 10⁹ USA).