Iz MySQL manuala sa
www.mysql.com :
- When using a normal web server setup,
images should be stored as files. That is, store only a file reference in the database. The main reason for this is that a normal web server is much better at caching files than database contents. So it it's much easier to get a fast system if you are using files.
- In many cases it's faster to access data from a database (using a live connection) than accessing a text file, just because the database is likely to be more compact than the text file (if you are using numerical data), and this will involve fewer disk accesses. You will also save code because you don't have to parse your text files to find line and column boundaries.
Dakle, to kazu ljudi koji stoje iza MySQL-a.
Dalje, ako bi trebao napraviti backup baze, kako bi izveo to u slucaju da je baza velika 1-2-3...n+ MB/GB ? Jesi li ikad to pokusao? Ja nisam uspio "normalno" napraviti backup jedne baze, koja je iznosila 224 MB (da li zbog manjka memorije u kompjuteru, da li zbog preopterecenja database enginea, da li zbog preopterecenja servera na kojem se nalazi baza... ne znam). A zamisli da se u bazi nalazi barem 10 000 slika od koja je svaka prosjecno 50 kb, pa jos dodaj neke tekstualne informacije.. Na sta bi to licilo? Teorija je jedno, a praksa drugo.
Ako bi snimao sliku u BLOB, onda to ispada snimanje fajla u fajl (BLOB u bazi je takodje fajl).
Evo jos nekoliko komentara:
- Data from a database is retreived one row at a time so you have to
wait for each image. Storing the path in the database allows you to
fetch a row, spawn a child process to fetch the image, and continue to
fetch rows from the database while the child processes handle getting
the images.
- Mysql will not cache the images. The OS however will cache disk
reads.
- If you need to fetch the files from the database your app needs to wait
until it has recieved the data. If you only store name/path info it will
take less time to fetch the data, ship it off to the browser which can
start fetching the images without connecting to the database again.
Sounds pretty logical.. and it gets worse if your site is hosted by an ISP
who is using a database server running on a seperate box..
Citat:
Napraviš plug-in za gnome-vfs da čita direktno iz baze, i zatim pomoću Nautilus-a, Gimp-a ili bilo kog drugog programa koji podržava gnome-vfs URI-je: otvaraš kao i svaki drugi fajl.
Ili, napraviš dodatak za Photoshop da direktno čita iz baze, ako si već navikao na njega.
Neko reče da sam tvrdoglav? :-P
Ma da... Zasto jednostavno, kad moze komplikovano.
Citat:
Znači, u tvom primeru sa faqts, prvi korak (za „db images“) je laganiji od prvog koraka servera, a druga dva koraka su jednaka sporijem od ta dva (pošto se događaju istovremeno, tome služe soketi), a svaki od ovih je takođe brži od prvog koraka direktnog čitanja. I eto, tu sad imamo 2 brža koraka+1 isti korak, a pri neposrednom čitanju imamo 1 sporiji korak+1 isti korak. Zašto bi 1 sporiji korak morao biti brži od 2 „brža“, zaista ne znam, ali vi neprestano tako tvrdite. Obratite pažnju na to da je seek time diska (čitaj: pronalaženje slike na disku) za nekoliko redova veličine veći od seek time-a za memoriju (čitaj: soket, pronalaženje fajla za mysql bazu,...).
Demagogijom i zbunjivanjem neces nista postici, jer u svemu tome nema ni "a" od argumenta koji bi prakticno bio prihvatljiv. Ja mislim da ne zelis priznati da nisi u pravu, da ne bi time slucajno "izgubio ugled sveznajuceg" i samim time povrijedio svoj ego. Tvrdoglav jesi, ali na svoju stetu.
Citat:
No, možda je zaista MySQL sporiji, ali to je onda njegov problem, a ne moj :-P
Eh sad, pokusavas se izvuci politickim odgovorom, jer si uvidio da je pohranjivanje slika u bazu neefikasnije od pohranjivanja linka u bazu, a samog fajla na filesystem.
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
Pitanje u vezi slika u mysql bazi...
