Martijn Voncken wrote: > On 8/21/05, Jason Tackaberry <[EMAIL PROTECTED]> wrote: >> On Sun, 2005-08-21 at 11:36 -0400, Jason Tackaberry wrote: >> > Assuming indexed queries, it's the number of rows returned that matters, >> > not the number of selects. A select which uses an indexed column which >> > returns 0 rows is very, very fast. It's practically a no-op. >> > >> But at any rate, I think this convincingly demonstrates the >> table-per-file-type, column-per-attribute approach is going to yield >> appreciably better performance. > > I tested and looked your code, yes it is faster. > Did you see mine? , there it's the other way around . > funny how different views and use cases yield totally different tests ;). > > your-test: all static info from this directory. > my-test:all dymanic info from this file.
You both do different stuff. Tack made one select to get all attributes from all files in a dir. I'm not so sure that's what you want to do, the data is useless. You select data from one file, which is faster because you only return attributes for one file. Question is: what do we want? In 90% of all cases we want a directory listing, not just one file. This means Tacks wins. One the other hand, my idea with one select to get basic file attributes and after that one select for each file could also work. But maybe not. Maybe we don't want to be that generic. Yes, generic is good, but what do we want at the end? A fast an small mediadb, not some huge moster that can handle everything. Maybe we make it very static. The table file contains everything we may need to do a query on and a pickled field for the rest. So we will always have album and artist, even for images. While this still makes sense, length for images and width for audio is stupid. But do we care? One table to hold everything soulds not so bad to me. Dischi -- Hit any user to continue.
pgpHh7bykeSgn.pgp
Description: PGP signature
