A da uzmes neki tool (recimo DB Designer), napravis ER model pa exportujes ili napravis screenshot pa da to vidimo. Na kraju kad usaglasimo to, mozes izgenerisati bazu direkt iz njega.

Recimo da bi povezao zanrove i filmove moras imati jednu 'medjutabelu' koja ima relaciju 1:M i N:1 sa obe tabele. Tj vishe filmova moze biti istog zanra i vishe zanrova moze biti u jednom filmu.

Hvala na odgovoru, i mislio sam da ce mi tako nesto biti neophodno.
Javicu se kad napravim ER model i jos malo razmislim o dizajnu...

Ja baš nisam neki filmofil ali da li može jedan film da ima više žanrova? Ako i može, možda je praktičnije opredeliti se za preovlađujući žanr ili proširiti listu žanrova na kombinacije horor-drama, komi-tragedija..... To u mnogome olakšava situaciju. Povezujuće tabele koje rešavaju veze više prema više su odlično i jedino rešenje za realizaciju ako se prethodno utvrdi da je to nužno. No to je možda moje nepoznavanje filmske materije .

Ono što sam hteo da ukažem je mogućnost da se u tabeli osobe doda memo polje za biografiju (jer skoro svi: režiseri, glumci i scenaristi imaju biografiju) i izbegnu dve tabele, koje bi uzgred budi rečeno ukoliko ostanu razdvojene, imale vezu 1:1.

Posmatranje filma_rejting, osoba_rejting, film_komentar ili osoba_komentar izvan entiteta film odnosno osoba je diskutabilno. Zato glasam da u budućim tabelama to budu kolone, a komentari recimo memo tipa (zavisi od SUBP-a), nasuprot ideji da egzistiraju kao samostalne tabele.

E sad biće verovatno i kontra mišljenja, jer memo polja koja su nepopunjana zauzimaju čini mi se isto resursa kao i kad su popunjana, pa je prethodno utvrđivanje procentualne popunjenosti od važnosti za donošenje odluke.

Da film moze da ima vise zanrova (imdb je organizovan po tom pricnipu) i sada u tabeli imam polje text tipa u koje aplikacija upise nesto ovako: Drama, Thriller Action, Crime.

A odgovarajuca PHP klasa je zaduzena za kreiranje upita sortiranja i sl, mada znam da su upiti ovako sporiji a i kod bi bio pregledniji da imam posebnu tabelu za to...

Razmisljao sam o memo polju za biografiju ali je problem sto biografija nece biti definisana za svaku osobu i pri dodavanju svakog novog glumca, rezisera, scenariste (ovo ide automatski) biografija je prazna tj. ne postoji.

Tako da ako tabela osobe ima 5000 redova, tabela biografije moze da sadrzi biografije za recimo svega 500 njih.

Evo recimo, spisak glumaca aktivnih u jednom filmu:



Sada su u bazi definisane biografije za samo troje njih...


Sto se tice tabela film_rejting, osoba_rejting idt...
Meni kao programeru je mnogo logicnije da imam posebne tabele i posebne klase za ovo jer mi je kod pregledniji, lakse ga dokumentujem i sl. Izmedju ostalog i postojeci rejting sistem sam realizovao na ovakav nacin jer sam mislio da tako treba

Getsbi, film moze biti 1,2,3.. zanrova tako da ne mozes napraviti sve kombinacije a da to ne bude konfuzno. Ja bih takodje sva memo polja koja nisu obavezna i cija je popunjenost manja od 50% drzao u odvojenim tabelama. U sustini bi na taj nacin odvojio 'vaznost' podataka i mislio na performanse aplikacije.

@ misk0
Ok. I razmišljao sam o takvim protivargumentima. Pogotovo ako su memo tipovi u pitanju.

Ako buduće tabele: film_rejting, osoba_rejting ... imaju još koju informaciju (još atributa) osim tih prezentovanih onda u redu. Učinili su mi se kao viseći atributi, pa sam poželeo da ih "udomim".