Jak zaprojektować dużą bazę danych?

Zastanawiam się jak najlepiej zaprojektować bazę danych do mojej strony, będzie tam spis seriali i odcinki, które będzie można zaznaczać jako obejrzane. Są użytkownicy, rejestracja, itd. Tylko, że problemem jest to, że musi tam być DUŻO tabel serialami. I zastanawiam się czy to dobry pomysł, tabele będą tworzone dynamicznie, z poziomu witryny, więc to dodatkowy problem. Dodatkowo w tabeli Users oprócz loginu,hasła,emaila, języka, trzeba też przechowywać listę obejrzanych, więc wymyśliłem, że będzie kolumna, Tables i tam będą zapisywane obejrzane w postaci
[T_(nazwa serialu)id:0, id:1, id:0],[T(nazwa serialu)id:0, id:1, id:0],[T(nazwa serialu)_id:0, id:1, id:0]
nazwa tabeli, potem id odcinka czyli odcinek 1 ma id 1, potem dwukropek i stan czyli 0 lub jeden, przcinek i tak dalej.

Możliwe rozwiązania:

1. Każdy serial to kolejna tabela, użytkownicy tworzą nowe tabele, i dodawany do kolumny Tables w tabeli Users
2. Jedna tabela Serials a w niej seriale, tylko tu powstaje problem bo serial ma atrybuty, i to zmienne w zależności od odcinka, takie jak rok, sezon, opis, nazwa odcinka i jak to w jednej tabeli trzymać? Trzymanie to pikuś w porówaniu z późniejszym wczytywaniem takiego długiego stringa na kilkanaście tysięciy znaków i rozdzielaniem go operowanie wyrażeniami.

Sam już nie wiem, jak to zaplanować :-(

Hej,
jeżeli to baza z serialami, to może jakaś taka bardzo duża nie będzie. Ja bym to zrobił tak, stworzyłbym tabele: USERS, SERIALE, OBEJRZANE. Szkic tabel:
USERS:

Nr/klucz | User | Dane Usera (parę kolumn)

SERIALE:

Nr/klucz | Serial | Nr odcinka | Pozostałe dane (parę kolumn)

OGLĄDANE:

Nr/klucz Usera | Nr/klucz Serialu

Jakoś tak, ale to tak na szybko :)

@hurgadion Czemu nie pomyślałem wcześniej, żeby zrobił tabele oglądane? Przecież to dobry pomysł, dzięki, na pewno znacznie lepszy, niż trzymanie wszystko w jednej komórce w tabeli Users .

Co do rozwiązanie z tablą SERIALE które podałes, to pojawia się problem bo wtedy to wyglądało by tak mnięj więcej:

ID |Nazwa Serialu|NumerOdcinka|NazwaOdcinka|Rok|itd.
---------------- |-----------------|---------------------|-------------- | -------------------
1 |Pitbull|1|Jakaś nazwa odcinka|2005|itd.
2 |Pitbull|2|Jakaś nazwa odcinka|2005|itd.
3 |Pitbull|2|Jakaś nazwa odcinka|2005|itd.
4 |Mr.Robot|1|Jakaś nazwa odcinka|2015|itd.
4 |Game of Throne|x|Jakaś nazwa odcinka|2017|itd.

Co powoduje problem, że trzeba by było oddzielać jakoś te seriale między sobą, niby można używać zawsze w zapytaniach SELECT FROM WHERE Nazwa SERIALU="$nazwaserialu" ale cz y to tak ma wyglądać?

@hurgadion: : No dobra, ale czy to nie będzie problemem odczytanie za każdym razem kilkunastu lub kilkudziesięciu tysięcy wierszy żeby pobrać np. 100?

Teraz pomyślałem, o problemie kolejnym! Co jakiś czas są nagrywane kolejne odcinki seriali, więc trzeba by je dopisywać, ale wtedy będą dopisane, za jakiś inny serial, podam przykład w tabeli

ID |Nazwa Serialu|NumerOdcinka|NazwaOdcinka|Rok|itd.
---------------- |-----------------|---------------------|-------------- | -------------------
1 |Pitbull|1|Jakaś nazwa odcinka|2005|itd.
2 |Pitbull|2|Jakaś nazwa odcinka|2005|itd.
3 |Pitbull|3|Jakaś nazwa odcinka|2005|itd.
4 |Mr.Robot|1|Jakaś nazwa odcinka|2015|itd.
5 |Game of Throne|x|Jakaś nazwa odcinka|2017|itd.
6 |Pitbull|x|Jakaś nazwa odcinka|2005|itd.
7 |MRoborl|x|Jakaś nazwa odcinka|2005|itd.

co to znaczy "tabele bedą tworzone dynamicznie" ? w jakim celu? Jeśli musisz coś takiego zrobić to znaczy, że coś źle zaprojektowałeś.

@mr_jaro też mi się tak wydaje, więc załóżmy, że nie będą dynamicznie tworzone, ale ręcznie je będę tworzył. Nadal jest pytanie jak zrobić.

Przecież @hurgadion podał, jak powinna wyglądać struktra tabel. Ja bym tylko zamienił zgodnie z dopiskiem @WeiXiao - dodałbym tabelę "Serile", a do tabeli "Odcinki" wstawiłbym klucz obcy do id_serialu.
A gdybyś się zainteresował bazami danych, to wiedzialbyś, że to podstawy podstaw. Podobnie , jak i to, że kolejność rekordów w tabeli w relacyjnej bazie danych nie ma znaczenia, bo i tak zazwyczaj dajemy jakiś ORDER BY.

ale gdyby zrobić tabelę seriale i tabelę odcinki, gdzie jest relacja 1 serial do wielu odcinków?

Chyba coś takiego

Tabela Seriale:

Tabela Odcinki:

Episode ID | Series ID | Episode Name
---------------- | -------------------
1 | 1 | Episode 5
2 | 1 | Episode 6
3 | 1 | Episode 7
4 | 2 | TestName1
5 | 2 | TestName2
6 | 2 | TestName3

@Marcin.Miga :* A gdybyś się zainteresował bazami danych, to wiedzialbyś, że to podstawy podstaw. Podobnie , jak i to, że kolejność rekordów w tabeli w relacyjnej bazie danych nie ma znaczenia, bo i tak zazwyczaj dajemy jakiś ORDER BY.* Już bez przesady, nie chodzi o to, że nie umiem zrobić bazy danych, tylko nie wiedziałem jak to zrobić tak powiedzmy logistycznie, żeby to było profesjonalnie napisane. Po to jest chyba forum, żeby pytać?
@WeiXiao : I o oto właśnie choidzło! Jest idealnie, ta tabela SERIES przyda się bardzo, ponieważ, będzie wybór serialu, więc to jest dobre bardzo.

Pozostaje tylko jedno pytanie, jak z działaniem sqlite z tak dużą bazą, jak będzie załóżmy hipotetycznie milion wierszy w seriale? Czy wtedy przeszukanie SELECTem będzie długo trwało? sqlite jest szybsze od mysql, ale nadal mam wątpliwości.

A bazy NoSQL rozważałeś, alternatywnie w bazie relacyjnej możesz trzymać dla serialu pole CLOB, a tam JSONa z propertiesami szczególnymi dla danego serialu.
Co prawda wyszukiwanie po jakimś szczególnym atrybucie serialu może być kłopotliwe... No ale kto poza Tobą wie jak baza będzie użytkowana ;-)

Tabela Users:

Tabela Ogladane:
ID |User| SeriesName | Watched |
---------------- | -------------------|-----------------
1 | Admin | Serial1 | 1:1,2:0,3:0,4:0,5:1,
2| Admin 2| Serial3 | 1:1,2:0,3:0,4:0,5:1,
3| Admin 3| Serial1 | 1:1,2:0,3:0,4:0,5:1,

Tabela Series:

Tabela Episodes

Nie znam się ale w Oglądane każdy rekord to raczej powinien być jeden odcinek. I powinny byc kolumny id serialu, sezon, numer odcinka i user.

I potem tylko robisz "wybierz * z ogladane gdzie serial=id serialu i user=id usera" i masz liste wszystkich widzianych odcinkow ze wszystkich sezonow.

@karpov: nie bądz taki skromy, dobrze mówisz, tak powinno być lepiej, tylko nie wiem jeszcze czy tabela oglądane ma zawierać tylko obejrzane odcinki czyli bez kolumny watched czy z kolumną watched, bo załóżmy, że zmieniam zadanie i odznaczam obejrzany odcinek, wtedy kasuje wiersz albo zmieniam watched na 0. Które rozwiązanie lepsze?

Tabela Users:

Tabela Ogladane:

ID |User| SeriesName | EpisodeID | Watched|
---------------- | -------------------|-----------------
1 | Admin | Serial1 | 1 | 1
2| Admin 2| Serial3 | 4| 1
3| Admin 3| Serial1 | 3 | 1

Tabela Series:

Tabela Episodes

Fajnie byłoby to hasełko jeszcze czymś posolić i zahaszować...
No i może dać jakiś username, bo nazwa ze spacją to taki trochę nieporęczny login.

@grzesiek51114 hesełko będzie solone, kodowane potem, na razie skupiam się na strukturze tych tabel. Co znaczy dać username? Chodzi ci co table users gdzie jest name? Już to zmieniłem nazwę na Username.

Co znaczy dać username? Chodzi ci co table users gdzie jest name? Już to zmieniłem nazwę na Username.

Jak zwał tak zwał, byleby wiedzieć co jest loginem, a co tylko nazwą użytkownika, która może być np. o wiele dłuższa.

Jezeli odznaczasz obejrzany to wyrzucasz rekord z tabeli. Wiec moim zdaniem lepiej zrezygnowac z kolumny watched i zalozyc ze w tabeli obejrzane masz tylko faktycznie widziane odcinki.

a może być md5 + sól?

Słabe. Polecam BCrypt.

Trochę o bezpieczeństwie haseł:
https://crackstation.net/hashing-security.htm

@karpov a jak to będzie wtedy wyglądać ID? Bedzie

ID:1
ID:2
ID:3

wyrzucam wiersz ID:2

i mam

ID:1
ID:3
i co z tą dwójką? Jest pomiijana?

@grzesiek51114 ok, zrobię bcrpyt

Jezeli ustawisz jako unilany klucz i żeby sam się zwiększał to tak, będzie pominięty - ale to nie jest żaden problem bo nie skupiasz sie na id tylko na serialu, userze i ewentualnie sezonie i odcinku.

@karpov Jedna sprawa jeszcze, pomyślałem, teraz, że w tabeli oglądane nie może być, User i SeriesName, bo nazwa usera może się zmienić, więc dam tam userID, i zamiast series name będzie seriesID

@CodeRZ: i tak właśnie powinieneś zrobić :) Na sztywno to wpisuj jedynie numer sezonu i odcinka.

W tabelach proxy, łączących związki wiele do wielu używaj zawsze kluczy głównych z tabel z końcowych.