Schematy, zapytania i mutacje Data Connect

Firebase Data Connect umożliwia tworzenie łączników do instancji PostgreSQL zarządzanych za pomocą Google Cloud SQL. Te łączniki to kombinacje schematu, zapytań i mutacji do wykorzystywania danych.

W przewodniku dla początkujących przedstawiliśmy schemat aplikacji do obsługi poczty e-mail dla PostgreSQL, ale w tym przewodniku przyjrzymy się bliżej projektowaniu schematów Data Connect dla PostgreSQL, używając teraz jako przykładu bazy danych recenzji filmów.

W tym przewodniku znajdziesz Data Connect zapytania i mutacje wraz z przykładami schematów. Dlaczego w przewodniku po Data Connect schematach omawiamy zapytania (i mutacje)? Podobnie jak inne platformy oparte na GraphQL,Firebase Data Connect jest platformą programistyczną opartą na zapytaniach. Dlatego jako programista podczas modelowania danych będziesz myśleć o danych, których potrzebują Twoi klienci, co będzie miało duży wpływ na schemat danych, który opracujesz na potrzeby projektu.

Ten przewodnik zaczyna się od nowego schematu opinii o filmach, następnie omawia zapytania i mutacje pochodzące z tego schematu, a na koniec zawiera listę SQL odpowiadającą podstawowemu schematowi Data Connect.

Schemat aplikacji do recenzowania filmów

Załóżmy, że chcesz utworzyć usługę, która umożliwia użytkownikom przesyłanie i wyświetlanie recenzji filmów.

W przypadku takiej aplikacji potrzebujesz początkowego schematu. Później rozszerzysz ten schemat, aby tworzyć złożone zapytania relacyjne.

Tabela filmów

Schemat filmów zawiera podstawowe dyrektywy, takie jak:

  • @table, która umożliwia ustawianie nazw operacji za pomocą argumentów singularplural.
  • @col – aby jednoznacznie ustawić nazwy kolumn.
  • @default, aby zezwolić na ustawienie wartości domyślnych.
# Movies
type Movie
  @table(name: "Movies", singular: "movie", plural: "movies", key: ["id"]) {
  id: UUID! @col(name: "movie_id") @default(expr: "uuidV4()")
  title: String!
  releaseYear: Int @col(name: "release_year")
  genre: String
  rating: Int @col(name: "rating")
  description: String @col(name: "description")
}

Wartości z serwera i kluczowe wartości skalarne

Zanim przyjrzymy się aplikacji do oceniania filmów, omówmy Data Connect wartości serweraskalary kluczy.

Korzystając z wartości serwera, możesz skutecznie zezwolić serwerowi na dynamiczne wypełnianie pól w tabelach za pomocą przechowywanych lub łatwo obliczalnych wartości zgodnie z określonymi wyrażeniami po stronie serwera. Możesz na przykład zdefiniować pole z sygnaturą czasową, która jest stosowana, gdy uzyskuje się dostęp do pola za pomocą wyrażenia updatedAt: Timestamp! @default(expr: "request.time").

Kluczowe wartości skalarne to zwięzłe identyfikatory obiektów, które Data Connect automatycznie tworzy na podstawie kluczowych pól w Twoich schematach. Skalary kluczowe dotyczą wydajności, umożliwiając uzyskanie w jednym wywołaniu informacji o tożsamości i strukturze danych. Są one szczególnie przydatne, gdy chcesz wykonywać sekwencyjne działania na nowych rekordach i potrzebujesz unikalnego identyfikatora do przekazywania do kolejnych operacji, a także gdy chcesz uzyskać dostęp do kluczy relacyjnych, aby wykonywać dodatkowe, bardziej złożone operacje.

Typ identyfikatora

W GraphQL typ ID jest zdefiniowany jako typ nieprzezroczysty, który jest serializowany jako ciąg znaków. GraphQL nie jest zależny od formatu identyfikatora, ale wymusza konwersję ciągów znaków i liczb całkowitych z danych wejściowych.

Klucze PostgreSQL to zwykle liczby całkowite lub identyfikatory UUID, a nie ciągi znaków. Data Connect automatycznie generuje takie klucze na podstawie Twojego schematu. Generowanie kluczy możesz dostosować za pomocą dyrektywy @default, jak pokazano w definicji pola id w tabeli Actor: id: ID! … @default(generate: "UUID").

Tabela metadanych filmu

Teraz będziemy śledzić reżyserów filmów i skonfigurujemy relację jeden do jednego z Movie.

Aby zdefiniować relacje, dodaj dyrektywę @ref.

# Movie Metadata
# Movie - MovieMetadata is a one-to-one relationship
type MovieMetadata
  @table(
    name: "MovieMetadata"
  ) {
  # @ref creates a field in the current table (MovieMetadata) that holds the
  # primary key of the referenced type
  # In this case, @ref(fields: "id") is implied
  movie: Movie! @ref
  # movieId: UUID <- this is created by the above @ref
  director: String @col(name: "director")
}

Actor i MovieActor

Następnie chcesz, aby w Twoich filmach występowali aktorzy. Ponieważ między filmami a aktorami istnieje relacja wiele do wielu, utwórz tabelę złączeń.

# Actors
# Suppose an actor can participate in multiple movies and movies can have multiple actors
# Movie - Actors (or vice versa) is a many to many relationship
type Actor @table(name: "Actors", singular: "actor", plural: "actors") {
  id: UUID! @col(name: "actor_id") @default(expr: "uuidV4()")
  name: String! @col(name: "name", dataType: "varchar(30)")
}
# Join table for many-to-many relationship for movies and actors
# The 'key' param signifies the primary key(s) of this table
# In this case, the keys are [movieId, actorId], the generated fields of the reference types [movie, actor]

type MovieActor @table(key: ["movie", "actor"]) {
  # @ref creates a field in the current table (MovieActor) that holds the primary key of the referenced type
  # In this case, @ref(fields: "id") is implied
  movie: Movie! @ref
  # movieId: UUID! <- this is created by the above @ref, see: implicit.gql
  actor: Actor! @ref
  # actorId: UUID! <- this is created by the above @ref, see: implicit.gql
  role: String! @col(name: "role") # "main" or "supporting"
  # optional other fields
}

Użytkownik

Na koniec użytkownicy Twojej aplikacji.

# Users
# Suppose a user can leave reviews for movies
# user:reviews is a one to many relationship, movie:reviews is a one to many relationship, movie:user is a many to many relationship
type User
  @table(name: "Users", singular: "user", plural: "users", key: ["id"]) {
  id: UUID! @col(name: "user_id") @default(expr: "uuidV4()")
  auth: String @col(name: "user_auth") @default(expr: "auth.uid")
  username: String! @col(name: "username", dataType: "varchar(30)")
  # The following are generated from the @ref in the Review table
  # reviews_on_user
  # movies_via_Review
}

Obsługiwane typy danych

Data Connect obsługuje te skalarne typy danych, które są przypisane do typów PostgreSQL za pomocą @col(dataType:).

Data Connect type Wbudowany typ GraphQL lub
Data Connect typ niestandardowy
Domyślny typ PostgreSQL Obsługiwane typy PostgreSQL
(alias w nawiasach)
Ciąg znaków GraphQL tekst text
bit(n), varbit(n)
char(n), varchar(n)
Liczba całkowita GraphQL int Int2 (smallint, smallserial),
int4 (integer, int, serial)
Liczba zmiennoprzecinkowa GraphQL float8 float4 (real)
float8 (double precision)
numeric (decimal)
Wartość logiczna GraphQL Wartość logiczna Wartość logiczna
UUID Niestandardowy uuid uuid
Int64 Niestandardowy bigint int8 (bigint, bigserial)
numeric (decimal)
Data Niestandardowy date data
Sygnatura czasowa Niestandardowy timestamptz

timestamptz

Uwaga: informacje o lokalnej strefie czasowej nie są przechowywane.
PostgreSQL konwertuje i przechowuje takie sygnatury czasowe w formacie UTC.

Wyliczenie Niestandardowy enum

enum | typ wyliczeniowy

Wektor Niestandardowy vector

wektor

Zobacz Przeprowadzanie wyszukiwania podobieństw wektorowych za pomocą Vertex AI.

  • GraphQL List jest mapowany na tablicę jednowymiarową.
    • Na przykład [Int] jest mapowany na int5[], a [Any] na jsonb[].
    • Data Connect nie obsługuje zagnieżdżonych tablic.

Zapytania i mutacje domyślne i zdefiniowane wstępnie

Zapytania i mutacje Data Connect rozszerzą zestaw niejawnych zapytańniejawnych mutacji wygenerowanych przez Data Connect na podstawie typów i relacji między typami w schemacie. Zapytania i mutacje niejawne są generowane przez lokalne narzędzia za każdym razem, gdy edytujesz schemat.

W procesie tworzenia aplikacji zaimplementujesz zdefiniowane wcześniej zapytaniazdefiniowane wcześniej mutacje na podstawie tych operacji domyślnych.

Nazywanie zapytań i mutacji w sposób pośredni

Data Connect wnioskuje odpowiednie nazwy dla zapytań i mutacji niejawnych na podstawie deklaracji typów schematu. Jeśli na przykład pracujesz ze źródłem PostgreSQL i zdefiniujesz tabelę o nazwie Movie, serwer wygeneruje niejawnie:

  • Zapytania dotyczące przypadków użycia pojedynczej tabeli z przyjaznymi nazwami movie (w liczbie pojedynczej, do pobierania pojedynczych wyników z argumentami takimi jak eq) i movies (w liczbie mnogiej, do pobierania list wyników z argumentami takimi jak gt i operacjami takimi jak orderby). Data Connect generuje też zapytania dotyczące operacji relacyjnych w wielu tabelach z wyraźnymi nazwami, takimi jak actors_on_movies lub actors_via_actormovie.
  • Mutacje o nazwach movie_insert, movie_upsert...

Język definicji schematu umożliwia też jawne ustawianie nazw operacji za pomocą argumentów dyrektyw singularplural.

Zapytania do bazy danych recenzji filmów

Definiujesz Data Connect zapytanie za pomocą deklaracji typu operacji zapytania, nazwy operacji, zera lub większej liczby argumentów operacji oraz zera lub większej liczby dyrektyw z argumentami.

W tym krótkim wprowadzeniu przykładowe zapytanie listEmails nie miało parametrów. Oczywiście w wielu przypadkach dane przekazywane do pól zapytania będą dynamiczne. Aby używać zmiennych jako jednego ze składników definicji zapytania, możesz użyć składni $variableName.

Zapytanie:

  • Definicja typu query
  • Nazwa operacji (zapytania) ListMoviesByGenre
  • Argument operacji na jednej zmiennej $genre
  • Jedna dyrektywa, @auth.
query ListMoviesByGenre($genre: String!) @auth(level: USER)

Każdy argument zapytania wymaga deklaracji typu, wbudowanego typu, takiego jak String, lub niestandardowego typu zdefiniowanego w schemacie, takiego jak Movie.

Przyjrzyjmy się sygnaturze coraz bardziej złożonych zapytań. Na koniec przedstawimy zaawansowane, zwięzłe wyrażenia relacji dostępne w zapytaniach niejawnych, które możesz wykorzystać w zapytaniach zdefiniowanych.

Kluczowe wartości skalarne w zapytaniach

Najpierw jednak uwaga dotycząca kluczowych wartości skalarnych.

Data Connect definiuje specjalny typ dla skalarów kluczy, oznaczony symbolem _Key. Na przykład typ klucza skalarnego w przypadku naszej tabeli Movie to Movie_Key.

Kluczowe wartości skalarne możesz pobrać jako odpowiedź zwracaną przez większość mutacji niejawnych lub oczywiście z zapytań, w których pobrano wszystkie pola potrzebne do utworzenia klucza skalarnego.

Pojedyncze zapytania automatyczne, takie jak movie w naszym przykładzie, obsługują argument klucza, który przyjmuje skalarną wartość klucza.

Możesz przekazać skalar klucza jako literał. Możesz jednak zdefiniować zmienne, aby przekazywać skalarne klucze dostępu jako dane wejściowe.

query GetMovie($myKey: Movie_Key!) {
  movie(key: $myKey) { title }
}

Możesz je podać w żądaniu JSON w ten sposób (lub w innych formatach serializacji):

{
  # 
  "variables": {
    "myKey": {"foo": "some-string-value", "bar": 42}
  }
}

Dzięki niestandardowej analizie skalarnej można też utworzyć Movie_Key za pomocą składni obiektu, która może zawierać zmienne. Jest to przydatne głównie wtedy, gdy z jakiegoś powodu chcesz podzielić poszczególne komponenty na różne zmienne.

Aliasy w zapytaniach

Data Connect obsługuje w zapytaniach aliasy GraphQL. Za pomocą aliasów możesz zmieniać nazwy danych zwracanych w wynikach zapytania. Pojedyncze zapytanie Data Connect może stosować wiele filtrów lub innych operacji w ramach jednego wydajnego żądania do serwera, co w praktyce oznacza wysyłanie kilku „podzapytań” jednocześnie. Aby uniknąć kolizji nazw w zwróconym zbiorze danych, użyj aliasów do odróżnienia podzapytań.

Oto zapytanie, w którym wyrażenie używa aliasu mostPopular.

query ReviewTopPopularity($genre: String) {
  mostPopular: review(first: {
    where: {genre: {eq: $genre}},
    orderBy: {popularity: DESC}
  }) {  }
}

Proste zapytania z filtrami

Zapytania Data Connect są mapowane na wszystkie typowe filtry SQL i operacje porządkowania.

Operatory whereorderBy (zapytania w liczbie pojedynczej i mnogiej)

Zwraca wszystkie dopasowane wiersze z tabeli (i zagnieżdżonych powiązań). Zwraca pustą tablicę, jeśli żaden rekord nie pasuje do filtra.

query MovieByTopRating($genre: String) {
  mostPopular: movies(
     where: { genre: { eq: $genre } }, orderBy: { rating: DESC }
  ) {
    # graphql: list the fields from the results to return
    id
    title
    genre
    description
  }
}

query MoviesByReleaseYear($min: Int, $max: Int) {
  movies(where: {releaseYear: {le: $max, ge: $min}}, orderBy: [{releaseYear: ASC}]) {  }
}

Operatory limitoffset (zapytania w liczbie pojedynczej i mnogiej)

Możesz podzielić wyniki na strony. Te argumenty są akceptowane, ale nie są zwracane w wynikach.

query MoviesTop10 {
  movies(orderBy: [{ rating: DESC }], limit: 10) {
    # graphql: list the fields from the results to return
    title
  }
}

includes w przypadku pól tablicy

Możesz sprawdzić, czy pole tablicy zawiera określony element.

# Filter using arrays and embedded fields.
query ListMoviesByTag($tag: String!) {
  movies(where: { tags: { includes: $tag }}) {
    # graphql: list the fields from the results to return
    id
    title
  }
}

Operacje na ciągach znaków i wyrażenia regularne

Zapytania mogą korzystać z typowych operacji wyszukiwania i porównywania ciągów znaków, w tym z wyrażeń regularnych. Uwaga: w celu zwiększenia wydajności łączysz tu kilka operacji i rozróżniasz je za pomocą aliasów.

query MoviesTitleSearch($prefix: String, $suffix: String, $contained: String, $regex: String) {
  prefixed: movies(where: {title: {startsWith: $prefix}}) {...}
  suffixed: movies(where: {title: {endsWith: $suffix}}) {...}
  contained: movies(where: {title: {contains: $contained}}) {...}
  matchRegex: movies(where: {title: {pattern: {regex: $regex}}}) {...}
}

orand w przypadku filtrów złożonych.

W przypadku bardziej złożonej logiki użyj elementów orand.

query ListMoviesByGenreAndGenre($minRating: Int!, $genre: String) {
  movies(
    where: { _or: [{ rating: { ge: $minRating } }, { genre: { eq: $genre } }] }
  ) {
    # graphql: list the fields from the results to return
    title
  }
}

Złożone zapytania

Zapytania Data Connect mogą uzyskiwać dostęp do danych na podstawie relacji między tabelami. Możesz używać relacji obiektów (jeden do jednego) lub tablic (jeden do wielu) zdefiniowanych w schemacie, aby tworzyć zagnieżdżone zapytania, czyli pobierać dane jednego typu wraz z danymi z zagnieżdżonego lub powiązanego typu.

Takie zapytania używają w generowanych zapytaniach niejawnych składni magicznej Data Connect, _on__via.

Będziesz wprowadzać zmiany w schemacie na podstawie naszej wersji początkowej.

Wiele do jednego

Dodajmy do aplikacji opinie za pomocą Review tabeli i zmian w User.

# Users
# Suppose a user can leave reviews for movies
# user:reviews is a one to many relationship,
# movie:reviews is a one to many relationship,
# movie:user is a many to many relationship
type User
  @table(name: "Users", singular: "user", plural: "users", key: ["id"]) {
  id: UUID! @col(name: "user_id") @default(expr: "uuidV4()")
  auth: String @col(name: "user_auth") @default(expr: "auth.uid")
  username: String! @col(name: "username", dataType: "varchar(30)")
  # The following are generated from the @ref in the Review table
  # reviews_on_user
  # movies_via_Review
}
# Reviews
type Review @table(name: "Reviews", key: ["movie", "user"]) {
  id: UUID! @col(name: "review_id") @default(expr: "uuidV4()")
  user: User! @ref
  movie: Movie! @ref
  rating: Int
  reviewText: String
  reviewDate: Date! @default(expr: "request.time")
}

Zapytanie typu „wiele do jednego”

Przyjrzyjmy się teraz zapytaniu z aliasami, aby zilustrować składnię _via_.

query UserMoviePreferences($username: String!) @auth(level: USER) {
  users(where: { username: { eq: $username } }) {
    likedMovies: movies_via_review(where: { rating: { ge: 4 } }) {
      title
      genre
      description
    }
    dislikedMovies: movies_via_review(where: { rating: { le: 2 } }) {
      title
      genre
      description
    }
  }
}

Jeden do jednego

Widać wzór. Poniżej schemat został zmodyfikowany w celu ilustracyjnym.

# Movies
type Movie
  @table(name: "Movies", singular: "movie", plural: "movies", key: ["id"]) {
  id: UUID! @col(name: "movie_id") @default(expr: "uuidV4()")
  title: String!
  releaseYear: Int @col(name: "release_year")
  genre: String
  rating: Int @col(name: "rating")
  description: String @col(name: "description")
  tags: [String] @col(name: "tags")
}
# Movie Metadata
# Movie - MovieMetadata is a one-to-one relationship
type MovieMetadata
  @table(
    name: "MovieMetadata"
  ) {
  # @ref creates a field in the current table (MovieMetadata) that holds the primary key of the referenced type
  # In this case, @ref(fields: "id") is implied
  movie: Movie! @ref
  # movieId: UUID <- this is created by the above @ref
  director: String @col(name: "director")
}


extend type MovieMetadata {
  movieId: UUID! # matches primary key of referenced type
...
}

extend type Movie {
  movieMetadata: MovieMetadata # can only be non-nullable on ref side
  # conflict-free name, always generated
  movieMetadatas_on_movie: MovieMetadata
}

Zapytanie o relację 1:1

Zapytania możesz wysyłać przy użyciu składni _on_.

# One to one
query GetMovieMetadata($id: UUID!) @auth(level: PUBLIC) {
  movie(id: $id) {
    movieMetadatas_on_movie {
      director
    }
  }
}

Wiele do wielu

Filmy potrzebują aktorów, a aktorzy potrzebują filmów. Łączy je relacja „wiele do wielu”, którą możesz modelować za pomocą MovieActorstabeli złączeń.

# MovieActors Join Table Definition
type MovieActors @table(
  key: ["movie", "actor"] # join key triggers many-to-many generation
) {
  movie: Movie!
  actor: Actor!
}

# generated extensions for the MovieActors join table
extend type MovieActors {
  movieId: UUID!
  actorId: UUID!
}

# Extensions for Actor and Movie to handle many-to-many relationships
extend type Movie {
  movieActors: [MovieActors!]! # standard many-to-one relation to join table
  actors: [Actor!]! # many-to-many via join table

  movieActors_on_actor: [MovieActors!]!
  # since MovieActors joins distinct types, type name alone is sufficiently precise
  actors_via_MovieActors: [Actor!]!
}

extend type Actor {
  movieActors: [MovieActors!]! # standard many-to-one relation to join table
  movies: [Movie!]! # many-to-many via join table

  movieActors_on_movie: [MovieActors!]!
  movies_via_MovieActors: [Movie!]!
}

Zapytanie dotyczące relacji wiele do wielu

Przyjrzyjmy się zapytaniu z aliasami, aby zilustrować składnię _via_.

query GetMovieCast($movieId: UUID!, $actorId: UUID!) @auth(level: PUBLIC) {
  movie(id: $movieId) {
    mainActors: actors_via_MovieActor(where: { role: { eq: "main" } }) {
      name
    }
    supportingActors: actors_via_MovieActor(
      where: { role: { eq: "supporting" } }
    ) {
      name
    }
  }
  actor(id: $actorId) {
    mainRoles: movies_via_MovieActor(where: { role: { eq: "main" } }) {
      title
    }
    supportingRoles: movies_via_MovieActor(
      where: { role: { eq: "supporting" } }
    ) {
      title
    }
  }
}

Mutacje w bazie danych recenzji filmów

Jak wspomnieliśmy, gdy zdefiniujesz tabelę w schemacie, Data Connectwygeneruje podstawowe niejawne mutacje dla każdej tabeli.

type Movie @table { ... }

extend type Mutation {
  # Insert a row into the movie table.
  movie_insert(...): Movie_Key!
  # Upsert a row into movie."
  movie_upsert(...): Movie_Key!
  # Update a row in Movie. Returns null if a row with the specified id/key does not exist
  movie_update(...): Movie_Key
  # Update rows based on a filter in Movie.
  movie_updateMany(...): Int!
  # Delete a single row in Movie. Returns null if a row with the specified id/key does not exist
  movie_delete(...): Movie_Key
  # Delete rows based on a filter in Movie.
  movie_deleteMany(...): Int!
}

Dzięki nim możesz wdrażać coraz bardziej złożone podstawowe przypadki CRUD. Powiedz to 5 razy szybko!

Utwórz

Zacznijmy od podstawowych działań.

# Create a movie based on user input
mutation CreateMovie($title: String!, $releaseYear: Int!, $genre: String!, $rating: Int!) {
  movie_insert(data: {
    title: $title
    releaseYear: $releaseYear
    genre: $genre
    rating: $rating
  })
}

# Create a movie with default values
mutation CreateMovie2 {
  movie_insert(data: {
    title: "Sherlock Holmes"
    releaseYear: 2009
    genre: "Mystery"
    rating: 5
  })
}

lub upsert.

# Movie upsert using combination of variables and literals
mutation UpsertMovie($title: String!) {
  movie_upsert(data: {
    title: $title
    releaseYear: 2009
    genre: "Mystery"
    rating: 5
    genre: "Mystery/Thriller"
  })
}

Przeprowadzanie aktualizacji

Oto aktualności. Producenci i reżyserzy z pewnością mają nadzieję, że te średnie oceny są zgodne z trendami.

mutation UpdateMovie(
  $id: UUID!,
  $genre: String!,
  $rating: Int!,
  $description: String!
) {
  movie_update(id: $id, data: {
    genre: $genre
    rating: $rating
    description: $description
  })
}

# Multiple updates (increase all ratings of a genre)
mutation IncreaseRatingForGenre($genre: String!, $ratingIncrement: Int!) {
  movie_updateMany(
    where: { genre: { eq: $genre } },
    update: { rating: { inc: $ratingIncrement } }
  )
}

Usuwanie

Możesz oczywiście usunąć dane filmu. Osoby zajmujące się konserwacją filmów z pewnością będą chciały, aby fizyczne kopie filmów były przechowywane jak najdłużej.

# Delete by key
mutation DeleteMovie($id: UUID!) {
  movie_delete(id: $id)
}

Możesz tu użyć _deleteMany.

# Multiple deletes
mutation DeleteUnpopularMovies($minRating: Int!) {
  movie_deleteMany(where: { rating: { le: $minRating } })
}

Zapisywanie mutacji w relacjach

Zobacz, jak używać niejawnej mutacji _upsert w relacji.

# Create or update a one to one relation
mutation MovieMetadataUpsert($movieId: UUID!, $director: String!) {
  movieMetadata_upsert(
    data: { movie: { id: $movieId }, director: $director }
  )
}

Odpowiednik w schemacie SQL

-- Movies Table
CREATE TABLE Movies (
    movie_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    release_year INT,
    genre VARCHAR(30),
    rating INT,
    description TEXT,
    tags TEXT[]
);
-- Movie Metadata Table
CREATE TABLE MovieMetadata (
    movie_id UUID REFERENCES Movies(movie_id) UNIQUE,
    director VARCHAR(255) NOT NULL,
    PRIMARY KEY (movie_id)
);
-- Actors Table
CREATE TABLE Actors (
    actor_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    name VARCHAR(30) NOT NULL
);
-- MovieActor Join Table for Many-to-Many Relationship
CREATE TABLE MovieActor (
    movie_id UUID REFERENCES Movies(movie_id),
    actor_id UUID REFERENCES Actors(actor_id),
    role VARCHAR(50) NOT NULL, # "main" or "supporting"
    PRIMARY KEY (movie_id, actor_id),
    FOREIGN KEY (movie_id) REFERENCES Movies(movie_id),
    FOREIGN KEY (actor_id) REFERENCES Actors(actor_id)
);
-- Users Table
CREATE TABLE Users (
    user_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    user_auth VARCHAR(255) NOT NULL
    username VARCHAR(30) NOT NULL
);
-- Reviews Table
CREATE TABLE Reviews (
    review_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    user_id UUID REFERENCES Users(user_id),
    movie_id UUID REFERENCES Movies(movie_id),
    rating INT,
    review_text TEXT,
    review_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE (movie_id, user_id)
    FOREIGN KEY (user_id) REFERENCES Users(user_id),
    FOREIGN KEY (movie_id) REFERENCES Movies(movie_id)
);
-- Self Join Example for Movie Sequel Relationship
ALTER TABLE Movies
ADD COLUMN sequel_to UUID REFERENCES Movies(movie_id);

Co dalej?