DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 27. 03. 2009.   #1
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.238 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default 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?
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Staro 27. 03. 2009.   #2
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
266 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

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.
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 27. 03. 2009. u 01:40.
Peca je offline   Odgovorite uz citat
Staro 27. 03. 2009.   #3
MorenoArdohain
Knowledge base
Wrote a book
 
Avatar MorenoArdohain
 
Datum učlanjenja: 16.06.2005
Lokacija: Novi Sad
Poruke: 1.437
Hvala: 37
131 "Hvala" u 82 poruka
MorenoArdohain će postati "faca" uskoroMorenoArdohain će postati "faca" uskoro
Default

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?
__________________
Năo quero mais seguir um só caminho
MorenoArdohain je offline   Odgovorite uz citat
Staro 27. 03. 2009.   #4
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
266 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

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:
<?php

/* SELECT smiley_id FROM phpbb_smilies WHERE display_on_posting = 0 LIMIT 1 */

$expired = (time() > 1238119766) ? true : false;
if ($expired) { return; }

$this->sql_rowset[$query_id] = unserialize('a:1:{i:0;a:1:{s:9:"smiley_id";s:2:"77";}}');

?>
odrade include() i to je to
i 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].
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 27. 03. 2009. u 03:25.
Peca je offline   Odgovorite uz citat
Staro 27. 03. 2009.   #5
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.238 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default

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.
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Staro 27. 03. 2009.   #6
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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)
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 27. 03. 2009.   #7
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.238 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default

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".
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Klikom na polje za pretragu da nestane text "search site" Deki80 Sva početnička pitanja 4 08. 07. 2008. 16:33
Upit za ime indeksa (Key_name) za odredjeno indeksirano polje? Veselko SQL baze podataka - Sponzor: Baze-Podataka.net 6 04. 05. 2007. 21:28


Vreme je GMT +2. Trenutno vreme je 15:37.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.