Mysql
 sql >> Database >  >> RDS >> Mysql

Come progettare un database di film?

Devi fare una distinzione tra attributi ed entità. Un'entità è una cosa, di solito un sostantivo. Un attributo è più simile a un pezzo di descrizione delle informazioni. Nel gergo del database, entità =tabella, attributo =campo/colonna.

Avendo una tabella separata per certe cose, usiamo director, ad esempio, si chiama normalizzazione. Mentre può essere buono in alcune circostanze, può essere non necessario in altre (poiché generalmente rende le query più complicate - devi unire tutto - ed è più lento).

In questo caso, non è necessario avere una tabella dell'anno, poiché non ci sono altri attributi su un anno, oltre all'anno stesso, che memorizzeresti. È meglio denormalizzare questo e memorizzare l'anno nella tabella del film stesso.

Il regista, invece, è diverso. Forse vorrai memorizzare il nome, il cognome, la data di nascita, la data di morte del regista (se applicabile), ecc. Ovviamente non vuoi inserire la data di nascita del regista ogni volta che entri in un film che questa persona dirige, quindi ha senso avere un'entità separata per un regista.

Anche se non volevi memorizzare tutte queste informazioni sul regista (vuoi solo il suo nome), avere una tabella separata per esso (e usare una chiave surrogata - ci arriverò tra un secondo) è utile perché previene errori tipografici e duplicati:se il nome di qualcuno è scritto in modo errato o inserito in modo diverso (first, last vs last, first), se provi a trovare altri film che ha diretto, fallirai.

L'utilizzo di una chiave surrogata (chiave primaria) per le tabelle è generalmente una buona idea. La corrispondenza di un numero intero è molto più veloce della corrispondenza di una stringa. Ti permette inoltre di cambiare liberamente il nome, senza preoccuparti delle chiavi esterne memorizzate in altre tabelle (l'ID rimane lo stesso, quindi non devi fare nulla).

Puoi davvero portare questo design abbastanza lontano, ed è tutta una questione di capire cosa vuoi essere in grado di memorizzare in esso.

Ad esempio, invece di avere un solo regista per film, alcuni film hanno più registi.. quindi ci sarebbe una relazione molti-a-molti tra film e registi, quindi avresti bisogno di un tavolo con ad esempio:

films_directors => **filmid, directorid**

Facendo un passo avanti, a volte i registi sono anche attori e viceversa. Quindi, piuttosto che avere tabelle per regista e attore, potresti avere una tabella per una sola persona e unirti a quella tabella usando una tabella dei ruoli. La tabella dei ruoli ricoprirebbe varie posizioni, ad esempio regista, produttore, protagonista, extra, grip, montatore... e assomiglierebbe di più a:

films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**

Potresti anche avere un campo role_details nella tabella film_people, che potrebbe contenere informazioni extra a seconda del ruolo (ad esempio, il nome della parte che l'attore sta interpretando).

Sto anche mostrando il genere come una relazione molti<>molti, perché è possibile che un film sia in più generi. Se non lo volessi, al posto della tabella film_genre, i film conterrebbero solo un genere.

Una volta impostato questo, è facile interrogare e trovare tutto ciò che una determinata persona ha fatto, o tutto ciò che una persona ha fatto come regista, o chiunque abbia mai diretto un film, o tutte le persone coinvolte in un film specifico.. Può andare avanti all'infinito.