[SQL] files or DataBase

[tomcask o_o]

Hiin 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. 

Re: [SQL] files or DataBase

[Jim C. Nasby]

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

Re: [SQL] files or DataBase

[Gregory S. Williamson]

As Jim N. already pointed out, extra layers do have a cost in time, and for 
some things straight disk is way faster.

A few points to consider (you don't give enough details for me to tell if this 
is true for you or not) ...

a) ACID -- what databases do best, making sure that everything that was changed 
is changed uniformly, etc. This can be hard to manage in a file system, 
although its not impossible, depending on what you are doing.

b) how much traffic ?  With small datasets most requests will find an already 
cached file and won't have to go to disk; this is true of databases as well If, 
OTH, you have either lots of requests for data that is rarely seen, or you have 
more data than can be cached, disk becomes a bigger issue.

c) Indexing and searching can be faster in a database (especially for 
complicated data sets) -- that's the payoff for the overhead of extra disk 
space for the indexes. Simple schemas can be implemented easily enough on a 
file system but rapidly become unworkable if you have data that needs to be 
addressed different ways (e.g. by name, and by date, etc.)

d) Update frequency -- databases do a better jopb of making sure that everyone 
sees a consistant selection; update a database with 10,000 items in a 
transaction, and everyone outside the transaction sees the old 10,000 items as 
a consistant whole; the transaction commits and instantly everyone will see the 
new 10,000. With a file system it can be hard to do this (although, again, 
there are ways). The more volatile the data the more I'd lean toward a 
database, personally. But again, without details of what you want to do it is 
very hard to say much other than generalities.

HTH,

Greg Williamson
DBA
GlobeXplorer LLC


-Original Message-
From:   [EMAIL PROTECTED] on behalf of tomcask o_o
Sent:   Thu 9/28/2006 3:37 PM
To: pgsql-sql@postgresql.org
Cc: 
Subject:[SQL] files or DataBase

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.



---
Click link below if it is SPAM [EMAIL PROTECTED]
"https://mailscanner.globexplorer.com/dspam/dspam.cgi?signatureID=451c4dbb67491336712104&[EMAIL
 PROTECTED]&retrain=spam&template=history&history_page=1"
!DSPAM:451c4dbb67491336712104!
---




---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly