|
LONGTEXT mysql polje
Imam neki projekat gde mi se pojavljuju tekstovi koji su duzi od 65K i TEXT polje mi nije dovoljno, pa sada razmisljam da li je bolje da se koristi LONGTEXT (ili MEDIUMTEXT) ili da lepo sve cuvam u neki file umesto u bazi... recimo da record cuvam u bazi, a te tekstove sa nekim {PRIMARY_KEY}.txt cuvam na disku?
Da li neko ima iskustva sa tim? Da li ta LONGTEXT polja nose neke skrivene probleme ili je savrseno sve jedno da li je TEXT ili LONGTEXT? |
mislim da je pametnije cuvati u txt fajlovima...
video sam recimo da mnogi cms-ovi keshiraju mysql podatke po /cache/*.php, pri cemu taj php fajl sadrzi array, pa se to ucita sa include() i onda kao da je mysql vratio rezultat. e sad, ako su oni dosli do zakljucka da ce citanje+parsiranje tog php-a da bude brze nego fetch-ovanje sa mysql-a... onda ce ovo tvoje da bude jos brze, jer samo imas citanje... p.s. obavezno flock() prilikom upisivanja podataka. |
Definitivno je bolje cuvati vece kolicine podataka (bilo da je to txt, image, ili nesto drugo) van baze, tj. kao eksterne fajlove, pogotovu kod veceg broja recorda.
Off Topic: Peco, mozes li mi navesti imena tih CMS-ova, prvi put cujem za tako nesto? |
nisu cms-ovi, samo mi bilo lakse tako da napisem, da ne objasnjavam jer su razliciti tipovi web aplikacija.
videh to kod phpBB3 i kod ActiveCollab-a :) ali oni ne keshiraju textove tu, vec uglavnom konfiguracije i razne krace podatke. a ako im se to 'isplati' sa kracim podacima - sa LONGTEXT ce jos vise da se isplati. primer kako to izgleda: Kôd:
<?phpi istu stvar ponove za ostale upite, sto znaci da ucitaju dvadesetak takvih fajlova prilikom svakog izvrsavanja skripte... pa ako su skontali da im to ne obara perfomanse vec ubrzava stvar - then do the same :) a Bluesman-u ne treba ni include() vec obican fopen+fread za .txt fajl, sto ce jos brze da ide [nema parsiranja kao u gornjem slucaju]. |
Da, planirao sam da čuvam u fajlovima na disku, mene je više interesovalo da li je stvarno neko radio sa tim LONGTEXT i kako to izgleda pošto može jako puno podataka da se upuše, verovatno otkida koliko mu je memorije potrebno.
@MorenoArdohain: To nije neobično, naročito za neke config variable koje se čuvaju u bazi, umesto da svaki put čitaš iz tabele, čitaš samo kada se nešto promeni i generišeš validan PHP file, sačuvaš negde a tvoj script uvek radi include tog fajla. Jedino što sam ja držao i rezervnu kopiju, pa ako se nešto desi, učitam to umesto generisanog php-a, čisto za svaki slučaj. Totalno offtoppic (a možda i nije?): Ja sam viđao slučajeve (ako kažem ko je tako radio - mnogi će se šokirati pošto za tu osobu misle da zna da programira), gde ne samo da svaki put čita config iz tabele nekom funkciojom readConfig("ime_config_varijable") koja da pokupi tu vrednost radi database query tipa: "SELECT value FROM config WHERE field='ime_config_varijable' ", već se dešava da za svaki put kada mu treba ta ista varijabla - poziva tu funkciju koja opet izvršava query. I da stvar bude još gora, na dosta mesta ima to u foreach petlji. Bili smo šokirani kada smo videli koliko se querija izvrašava po strani, to je išlo skoro do 100, što je bez obzira da li je query brz ili ne - neverovatan propust. To je onaj isti koji ima preko 300 klasa i u jednom config.php koji se učitava na svakoj strani - sve ih include-uje... šta će čovek... bolje da bude sigurno nego da razmišlja da li je include-ova neku klasu. Mada na istom mestu od iste osobe sam video i druge "tajne programiranja", recimo konektovanje na bazu u foreach petlji... znači za svaku iteraciju. To nije propust ni omaška jer se ponavlja na nekoliko mesta, to je očigledno "stil programiranja" :) Off Topic: Grozan sam danas... šta ću, samuraj me je zagrejao pa sada pichim full speed. :) |
sad cu ja da ispadnem vecna opozicija, ali ne vidim zasto to ne bi cuvao u bazi, uz pretpostavku da zelis da operises na tim podacima na neki relacioni nacin. Ako se podaci samo arhiviraju onda je naravno najlogicnije da ih snimis u fajl (i zaboravis na njih do daljnjeg:)), ali u svim ostalim slucajevima baza je optimizovana za rad sa podacima, tome baze sluze, i sigurno je brza (i sigurnija) nego da ti implementiras tu istu logiku u php-u (a imas recimo i fulltext search, i druge bonuse, ako zatreba)
|
Nisi opozicija, nisam ni ja protiv opšteg čuvanja u bazi, ali to opet zavisi od slučaja do slučaja, nekada je efikasnije jedno a nekada drugo. Ja generalno ne znam koliki taj podatak može da bude, od par karaktera do par miliona karaktera, sve je moguće i zavisi samo od usera... čak je vrlo verovatno da bude veći od 500.000 karaktera. Ako pukne script zbog memorije, taj podatak teško mogu da izvučem iz baze, ali ako je sačuvan u file, onda mogu bar parcijalno da čitam i sklapam "puzzle" (može to i iz baze ali deleko teže).
U mom slučaju ne treba mi ni search ni bilo šta slično, jedino što može da se desi je da korisnik zatraži taj podatak preko drugih parametara (primary key), tako da stvarno nemam puno razloga da čuvam to u bazi osim što je onda "sve na jednom mestu" i ne moram da brinem o integritetu podataka, odnosno ako uradim dump baze, da li sam pokupio i podatke koji nisu u bazi već na disku - samo to predstavlja problem, ali mislim da je to mala cena za ono što se dobija. Osim toga, razmišljam da ono što je na disku onda mogu dodatno da gzip-ujem, pa možda tako gzip-ovano da držim u bazi u nekom BLOB polju... pošto je običan tekst, sigurno će i kompresija da bude dobra, tako da sam i rešio problem sa "raštrkanim podacima". |
| Vreme je GMT +2. Trenutno vreme je 07:51. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.