Przechowywanie dużych tekstów PLIK czy MYSQL?, co najbardziej funkcjone i co wybrać? Opcje

[Dynuel]

Witam

Pracuję właśnie nad serwisem i stanął przedemną problem, a mianowicie nie potrafię wybrać metody przechowywania dużych tekstów. Niegdyś robiłem to w plikach, lecz tylko ze względu na to iż gdy wprowadziłem około 100 tekstów do MySQL'a u mnie na kompie, to tabela nie chciała zbytnio pracować. Ogólnie był bym bardziej skłonny do MySQL'a lecz nie wiem jakie rodzaje pol wybrać i jak skonstruować tabelę by poprawnie działała.

Przy wyborze metody chciałbym zaznaczyć iż teksty będą szły w tysiącach, lecz nie będą to posty jak na forum, tylko dluższe i krótke teksty, zajmujące po pare stron A4.

Z góry wielkie dzięki

ps. no i oczywiście przechowywanie tekstow w mysql, ulatwiło by wyszukiwanie

Ten post edytował Dynuel 19.06.2005, 07:33:50

[dag]

Obecnie odchodzi się od trzymania danych w zwykłych plikach tekstowych na rzecz baz danych z prawdziwego zdarzenia. Jak sam napisałeś liczba tekstów będzie liczona w tysiącach. Z całą pewnością będzie łatwiej operować na takiej liczbie tekstu poprzez interfejs bazy danych.

Z resztą temat był już poruszany na Forum. Poszukaj. Są tam przedstawione plusy i minusy obu rozwiązań. Jak dla mnie więcej zalet ma baza danych (np. MySQL czy PostgreSQL).

[Dynuel]

no dobra, ja tez jestem za mysql, tak wiec dokonalismy wyboru, ale jakie rodzaje pol wybrac (text, longtext itp)(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) ? i jak skonstruować tabelę z tekstami?? trzymać w jednej tabeli wszystko czyli : tytul, id, date, autora... tutaj kilkanascie roznych pol... i tresc, czy moze w jednej tabeli trzymac wszystkie pierdoly i informacje a w drugiej tylko id i tresc?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) ? tak aby wszystko ladnie chodzilo i się nic nie walilo.

dzieki

[dag]

Kod

tabela "authors"
author_id
name
email

tabela "articles"
id
title
body
author_id
date

Typy kolumn w MySQL:
http://dev.mysql.com/doc/mysql/en/column-types.html

Tutaj masz typy kolumn z tekstem:
http://dev.mysql.com/doc/mysql/en/string-type-overview.html

Ten post edytował dag 19.06.2005, 08:40:20

[Dynuel]

aktualnie najdluzszy tekst ktory posiadam w serwisie ma 1 405 585 znakow, a będą jeszcze znacznie dluzsze (no ale 10x dluzsze to chyba nie), wiec z tego co wyczytalem to w gre wchodzą jedynie dwa pola albo cztery, zalezy jak na to patrzec

#

MEDIUMBLOB

A BLOB column with a maximum length of 16,777,215 (2^24 − 1) bytes.

#

MEDIUMTEXT

A TEXT column with a maximum length of 16,777,215 (2^24 − 1) characters.

#

LONGBLOB

A BLOB column with a maximum length of 4,294,967,295 or 4GB (2^32 − 1) bytes. Up to MySQL 3.23, the client/server protocol and MyISAM tables had a limit of 16MB per communication packet / table row. From MySQL 4.0, the maximum allowed length of LONGBLOB columns depends on the configured maximum packet size in the client/server protocol and available memory.

#

LONGTEXT

A TEXT column with a maximum length of 4,294,967,295 or 4GB (2^32 − 1) characters. Up to MySQL 3.23, the client/server protocol and MyISAM tables had a limit of 16MB per communication packet / table row. From MySQL 4.0, the maximum allowed length of LONGTEXT columns depends on the configured maximum packet size in the client/server protocol and available memory.

tak wiec mam wybrac mediumtext czy longtext, czy longtext nie bedzie troche przy duze?? i nie bedzie mialo jakiegos wielkiego wplywu na bazę danych?? i dostęp do danych?? a i co mam wybrac blob czy text, czym to sie w ogole różni bo ja zbytnio sie nie znam, a nie widze żadnej roznicy.

a odnosnie konstrukcji tabeli, to moge wszystkie informacje trzymac w jednej tabeli razem z tym wielkim polem z trescią tak?? tylko zaznaczam ze tych dodatkowych pol bedzie z 15, typy: int, varhar oraz text

Ten post edytował Dynuel 19.06.2005, 09:09:00

[NuLL]

gdy wprowadziłem około 100 tekstów do MySQL'a u mnie na kompie, to tabela nie chciała zbytnio pracować.

Bo pewnie źle ją zaprojektowałeś.

Mogę ci tylko powiedzieć, żę w pracy na firmowym serwerze jest tabela z ponad 2,5 milionem rekordów w tabeli i MySQL jakoś nie narzeka.

Są znane przypadki gdzie MySQL chodził w 5 miliardami rekordów tabeli.

Jeśli nie będziesz miał tekstów dłuższych niż 16 MB (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) to MEDIUMTEXT rozwiązuje sprawe.

[Dynuel]

ok, to sprawe wyboru typu pola, mamy z głowy, wielkie dzięki, a mógłbyś powiedzieć mi teraz jak zaprojektować tabelę?? treść i id, w jednej tabeli, a dodatkowe dane w drugiej?? czy wszystko w jednej??

[SongoQ]

Mysle ze w 1 tabelce, wazne jest to zeby podczas wyciagania rekordow i wykonywania zapytan nie robic czegos takiego jak SELECT * bo to Ci strasznie zamuli baze. Jesli bedziesz mial 2 tabelkach podobna sprawa moze byc przy relacjach, ale wtedy dla dodatkowej tabeli masz dodatkowe indexy, dodatkowe laczenie tabel itd a wiadomomo ze wtedy wydajnosc spada.

Kolejne sprawa to LIKE w wyszukiwania, tez moze byc problemem, ale mozna zastosowac indeksowanie slow i sprawa jest bardziej jasniejsza a szczegolnie dla pol o 4BG znakow.

[Dynuel]

indeksowanie slow powiadasz?? według mnie to chyba troche lipa, w phpbb, to wlasnie ta tabela zajmuje najwięcej miejsca. a tak w ogole to na czym to wlasciwie polega bo nie bardzo wiem:]

[SongoQ]

W 1 tabelce masz zapisane niepowtarzajace sie slowa, a w 2 masz w jakim rekordzie wystepuje jakie slowo.

Czyli zapytanie dziala tylko na relacjach i wszystko odbywa sie po przez id, gdzie wszedzie sa indeksy, czyli dziala wydajniej niz przeszukiwanie LIKE w tabelach z tekstem.

Pomysl sobie szukasz w milionie rekordow slowa ala a pole ma 4GB tekstu.

[Dynuel]

no racja, ale jezeli mam indeksować każde slowo i jeszcze w dodatku wszystkie posty w których ono wystąpiło, to to troche moze zajmować

no ale dzięki, a mógłbyś jeszcze zerknąć na podobną sprawę http://forum.php.pl/index.php?showtopic=31826

[SongoQ]

no racja, ale jezeli mam indeksować każde slowo i jeszcze w dodatku wszystkie posty w których ono wystąpiło, to to troche moze zajmować

To zalezy co chesz osiagnac. Albo lepsza wydajnosc bazy albo miejsce. Bo indeksowanie wiadomow tez troche zajmuje objetosci. Wszystko zalezy od Ciebie i specyfikacjie projektu.

no ale dzięki, a mógłbyś jeszcze zerknąć na podobną sprawę http://forum.php.pl/index.php?showtopic=31826

OK (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)