Hi folks, when you think about what the job of an operating system is, you'll find he solution why database-stored data (Data, names blobs, anything) CAN (not must) be retrieved faster than to access a file in the system's (hirachical!!!) file structure. The first reason is this Tree-oriented thing for a directory The second is: a database is optimized for fast data finding (that's where keys are for) the os relays more on sequencial searching and just caching some hundred entries(which is quite a lot in terms of a human user!). The last MIGHT be some extra-added break as an anti-virus-software which at least has to check whether to scan that file or not. If you happen to have a directory with a couple of thousand files, youz'll see, how long it takes to open that dir in the explorer. That's rather long compared to showing the records of a db in a grid, even if there are some thousands.
Now, with that knowlege that a DB might be better how to proceed, where are the pitfalls The database file(s) whichever you use tend to become bigger and bigger. Handling of big files (backup, move copy) becomes harder with increasing dimensions. and the danger of corruption grows with the filesize. What leads out of that? Divide an conquer! DBs are (mostly) able of beeing spread over several files. (Interbase/firebird at least is) You could as well spread your Files into a hundred sub-Directories having not more than 1000 files in a dir which does not slow down the os too much. and having the file-paths stored in the db. This would have the advantage of accessing the files witout using the database (if you know the name of the file) So it stays the same all over: it's up to you to decide what2do! make up a list of goodies and not so goody for your choices and let your customer decide whith what he'll live. Have fun! Bob > > On 4/20/05, David Bolton <[EMAIL PROTECTED]> wrote: > > You would think so,. but I worked at (long defunct) dotcom where house > > pictures were stored in Sql Server 6.5- some 43,000 of them. If you have > > that quantity in a folder it slows down Windows a little accessing them > but > > in a database (stored I guess as part of a large binary file) they were > very > > quick to retrieve. > > That sounds veryyy strange for me :) > > For me the most time-consuming operation is to retrieve the image data > from the hd... Looking for the file seems to be fast... Even if the > database index structure is "thousands" better than the OS one, it > still making no sense for me, since the database will look for the > record and then read from the hd and retrieve to the user in a kind of > "get and pass" process... While the direct hd access will just find > the file and start retrieving to the user > > > It amazed me but it worked very well. I suggest you do > > some experiments before deciding which way to go. > > I'm also impressed out hehe!!! But i dont have such application to > test, and a real test must include real people using the solution =] > > Wasn't your application listing files? This might be slow if compared > with a nice database and your advanced indexes :) > > > *That's just my personal opinion, nothing tested =] > > > -- > "ME ALIMENTE [http://br-linux.org/noticias/002750.html] hehe" > "Invente, Tente!!! Fa�a um c�digo eficiente" (Jonas Raoni haha) > > Jonas Raoni Soares Silva > --------------------------- > Desenvolvedor de aplica��es > jonasraoni at gmail dot com > http://www.joninhas.ath.cx:666 > > > ----------------------------------------------------- > Home page: http://groups.yahoo.com/group/delphi-en/ > To unsubscribe: [EMAIL PROTECTED] > Yahoo! Groups Links > > > > > > > ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
