Re: DB vs FS, cookies vs http authentication

[Davi Leal]

Dion Rasmussen wrote:
> Each offer can be stored (dynamically) as a file and shown off (dynamically
> eventually cached statically) with a HTML template using the standard
> file-system as the database-engine instead of some special database.

If a user stores 2 or 3 job offers as files, each file will keep her personal 
information duplicated.

That duplication is raised by the relational nature of the information the 
webapp work with. The offer information is related with the personal 
information of who publish it.

IMHO a relational database as PostgreSQL is the best way to manage such 
relational information.

Duplication is a nightmare for maintenance.


Anyway, this project could use a database to keep the information and files 
only for cache purposes.

Designing a file based cache system is independent of using or not a database 
based design.  However, note a cache system is not needed. The host 
gnuherds.org is using has all the information loaded in memory!  There is not 
best cache than memory.


> Furthermore the standard HTTP authentication can be used with eventual
> secure socket layer constraints instead of relying on cookies for security.

There are several HTTP authentication methods. What specific one do you think 
the project should use?


> Sometimes special databases can be useful but it's a bit easier and a
> better finish to just use the standard file-system for varying data as well
> as static data, for the sake of data-management-ease as well as security
> layout.

IMHO to keep relational information a relational database engine is the only 
sane way to go, as exposed above. Duplication is a nightmare for maintenance.

> And once again, a database transaction specification is as complex as
> locking a file :)

Yes, the complexity of its API is similar, but just locking a file will not 
work for us.  When you lock a file for writing anybody more can write to it!

When you open a database transaction to write on PostgresSQL another user can 
open her own transaction to write too.  Several transactions can be writing 
at the same time in the PostgreSQL engine.

We need to support more than one user working at the same time. That is to 
say, we need concurrency support.

Besides, the relational nature of the information is too against the file 
system based storage idea.