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
Pełna wersja: Przechowywanie dużych tekstów PLIK czy MYSQL?
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).
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).
no dobra, ja tez jestem za mysql, tak wiec dokonalismy wyboru, ale jakie rodzaje pol wybrac (text, longtext itp)
? 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?? tak aby wszystko ladnie chodzilo i się nic nie walilo.
dzieki
? 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?? tak aby wszystko ladnie chodzilo i się nic nie walilo.dzieki
Kod
tabela "authors"
author_id
name
email
tabela "articles"
id
title
body
author_id
date
author_id
name
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
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
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
Cytat
#
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.
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
Cytat
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
to MEDIUMTEXT rozwiązuje sprawe.
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??
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.
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.
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:]
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.
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.
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
no ale dzięki, a mógłbyś jeszcze zerknąć na podobną sprawę http://forum.php.pl/index.php?showtopic=31826
Cytat
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.
Cytat
no ale dzięki, a mógłbyś jeszcze zerknąć na podobną sprawę http://forum.php.pl/index.php?showtopic=31826
OK
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.