On Fri, Sep 29, 2006 at 12:37:56AM +0200, tomcask o_o wrote: > Hi > > in advance, sorry for my english. > > in a Web server as is the best option? > > to accede to db to show the contents or to accede to static files modified > by scripts when the content of db has been modified. > > That the habitual thing is to work directly with db and to give back to the > results mounting the page then. > > But I believe that serious much more fast if they were directly the files > and on the other hand in the server of local way executed scripts whom the > changes of the files in a aux table verified, and published the files that > have undergone changes. > > that to both consider the yield of the server in the diferents scenes. > > Greetings and thanks.
The more code that sits between you and the data, the longer it takes to get at the data. Filesystems try and minimize that code path so that you can get at your data as fast as possible. Databases on the other hand provide you with a rich query environment that makes it easy to filter, format and manipulate data. So... if you're just talking about spewing data out a pipe without having to process it, nothing will beat a filesystem. So if your web content almost never changes, you'll probably be better off with static files that are re-generated from the database as needed. If most of your page content is static, with a small amount that's dynamic, you might want to mix and match the two somehow. Here's what you don't want to do: have each page issueing 100 queries to the database. That's a great way to kill your performance and/or scaleability. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend