Cześć.

Chciałbym zapytać was, drodzy forumowicze, o poradę. Piszę bardzo prostą stronę, a właściwie książkę online. Wszystko jest podzielone na rozdziały. Chciałem, aby każdy rozdział miał swój link i ładował się na odpowiedniej podstronie. Teraz chciałbym zapytać, jak najlepiej to rozwiązać. Chodzi mi tutaj o to, gdzie przechowywać tekst książki. W normalnych plikach widoku (używam frameworka), które ładować w zależności od tego jaki rodział wybierze użytkownik, czy może w bazie danych, czy jeszcze inaczej?
Pytanie może banalne, ale nie wiem jak najlepiej to zrobić. Dodam, że książka ma około 60 kartek A4 czcionką 12, więc tekstu jest naprawdę dużo.

Pozdrawiam, Kacper.

po to są bazy danych aby trzymać w nich informacje

Oczywiście, lecz tych danych będzie BARDZO dużo. Wyobrażasz sobie cały rozdział w jednej komórce w tabeli? W takim razie jak to optymalnie podzielić, aby porcje danych nie były zbyt duże, a z kolei żeby nie było zbyt dużo zapytań?

nie wiem jak chcesz aby ta strona z książką wyglądała ale rozdział też chyba można podzielić np na strony? pamiętaj tylko że jeśli chodzi o wydajność zapytań np wyszukiwania w takiej strukturze to warto jest załozyć index full textowy

Zwróć uwagę, że w chwili obecnej możesz iść w dwie strony. Albo wszystko przerzucasz na jedną bazę danych albo rozbijasz to na dwie. Jedna odpowiadać będzie za dane relacyjne a druga za sam tekst i jego przeszukiwanie. To wcale nie jest złe. Za dane relacyjne może odpowiadać przykładowo MySQL, zaś za obsługę tekstu jakaś baza noSQL (choćby MongoDB) lub silnik wyszukiwawczy pokroju Sphinx-a. Owszem, wprowadza to pewien poziom komplikacji kodu, ale mocno zwiększa wydajność w przypadku rozrastających się dużych ilości tekstu. A z czymś takim tutaj mamy do czynienia. Poczytaj sobie o tym co wspomniałem i zastanów. Dobrze zastosowane powinno być łatwo skalowalnym i wydajnym rozwiązaniem.

Duże porcje danych to nie jest żaden problem dla baz danych. Nawet jakby było tysiące wierszy.

Same duże porcje to nie problem - prawda. Gorzej gdy na tych porcjach trzeba operować. Wyszukiwarka w tekście to zazwyczaj masakrator wydajności. Stąd od razu rzuciłem Sphinxem jako przykładem. Ogólnie wiadomo nieco bardziej zaawansowanym programistom, że w takich wypadkach najlepiej właśnie z tego typu silników skorzystać, by dla zwiększenia wydajności skorzystać z funkcjonalności shardingu oraz replikacji. Oba mają wpływ na wydajnośc oraz bezpieczeństwo, gdyż można dane porozmieszczać w różnych maszynach fizycznych. Więc nawet pad którejś z nich oznacza dostęp do pełnego kompletu danych. Rzucę więc słowami kluczowymi: Solr, Lucene, Sphinx, ElasticSearch. Uwierz, że gdy baza bardzo mocno się rozrośnie, na któryś z nich zapewne spojrzysz czułym wzrokiem Wyobrażasz sobie przypuśćmy to forum bez takowego silnika pod spodem? Niby mało tekstu się wydaje, ale tu już jest z tego co kojarzę ponad milion postów. Goły MySQL z jego full-text-searchem by zdechł dawno. Niby można próbować się bronić horyzontalnym partycjonowaniem tabel w MySQL, ale to też tylko pewne obejście problemu, a nie jego całkowite rozwiązanie.

Bardzo dziękuję wam za rzeczowe wypowiedzi i pomoc. Zagłębie się w temat.
Pozdrowienia.

@thek odjechałeś lekko z tym sphinxem do prostych stronek, gdzie nikt nie liczy milisekund, zwykły full text wystarczy. Jako przykład - stwórz sobie testową tabelę (myisam), dodaj 100k rekordów z 2-3k znaków w komórce, wyszukiwanie nie zajmie dłużej niż 0.01-0.5 sekundy (oczywiście wiele czynników wpływa na szybkość wyszukiwania)


@netbeans proponuję następujący podział

książka
ksiazka_id | tytul | opis itp.

rozdzial
rozdzial_id | ksiazka_id | tytul | ...

strona
strona_id | rozdzial_id | strona_nr | tekst

@CuteOne: Dlatego zwróć uwagę co pogrubiłem w swoim poście. Silniki te to plan na przyszłość. Początkowo nie pokażą co potrafią. Baa... Potrafią wręcz popsuć wydajność, jeśli używa się ich nieumiejętnie. Jednak sama ilość tekstu wynikająca z zagadnienia oraz wykorzystania sugeruje już na starcie budowę pod kątem przyszłego ich użycia. I to raczej prędzej niż później. Co do testowej tabeli to najlepsza byłaby faktyczna przynajmniej kilkuset lub kilku tysięcy książek. Utworzenie indeksu to pikuś ale jego aktualizacja z czasem zacznie odgrywać coraz bardziej istotną rolę. Wystarczy poczytać ile w podanych przeze mnie rozwiązaniach potrafi aktualizacja indeksów trwać

Skoro jesteśmy przy full-text warto wspomnieć o fakcie, że na dużych ilościach danych indeks tego typu rozrasta się bardzo szybko. Do tego domyślne jego ustawienia sprawiają, że pewne słowa z niego wylatują co sprawi, iż zamiast jednego wyszukiwania będzie trzeba zaimplementować do głównego także wyszukiwania "uzupełniające" w określonych przypadkach. O takich rzeczach na początku się nie wie. Poza tym większość osób patrzy tylko na wielkość tabel, pomijając kwestię wielkości indeksów, które w tym wypadku potrafią być naprawdę duże. Zauważmy też, że w tym wypadku nie ma tak różowo, ponieważ wyszukiwanie będzie przebiegać po kilku kolumnach a nie jednej. Bo pewnie indeks miałby być założony jednocześnie na: imię i nazwisko autora/ów, tytuł, treść, opis. W tej sytuacji kończymy nie na zapytaniu do jednego indeksu ale kilku zapytaniach lub pytaniu kilku indeksów jednocześnie. Jak teraz określisz prawdopodobieństwo trafności, czyli popularny score, według którego posortujesz wyniki? To są właśnie rzeczy o których początkujący nie wiedzą, myśląc że istnieją jakieś magiczne sposoby i sama baza danych to zrobi za nich.