On Wed, May 7, 2008 at 8:26 PM, Davi Leal <
address@hidden> wrote:
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.