Re: DB vs FS

[Davi Leal]

Dion Rasmussen wrote:
> The relational nature of job offers aren't more complex than that allowed
> by a standard file-system

Our current job offers are composed by several information sets:

  1. The personal information of whom post the job offer.

  2. The job offer description itself.

  3. State of user subscription.

  4. etc. ...

Those (1.) and (2.) sets have a 1-to-N relationship between them. That is to 
say, 1 person can create N job offers, being N = 100, 1000, or just 5.

If you choose to keep such information in files, you will have to duplicate 
the person information in each "job-offer-file" or dynamically merge the 
person file with the offer description file.

To do that kind of merge of information there is not best way that use a 
relational database. Relational databases are to manage relational 
information.

The usual GNU/Linux file systems does not allow that kind of 1-to-N relation 
among files.

If you take into account the (3.) and others sets of information the design 
will be obvious; use a relational database.

Besides, if we develop such kind of merge on files the automatic translation 
of offers will be more complex.

> and duplication of identification numbers aren't 
> much different from that of PostgresSQL.

The duplication of identification numbers is the way to implement the 
relationship in relational databases.

Relational databases are a very well tested technology, when used to manage 
relational database.

I do not know any stable filesystem which be a well tested technology to 
manage _relational_ information.

> Many file-systems even have automatically generated time-stamps as pr.
> default properties. 


> As another plus, by using files for user input, job-offers could easily be
> distributed over nfs, ftp or via rsync or even http by linking
> job-offer-files to some syndication directory.

The current job offer design allows automatic translation to any of the webapp 
supported languages. We could not do that easily if we store the offers in 
files.

We do not need store offers on files to be able to distribute it.


> Job-advertisers could have their own advertiser directories with a
> .htaccess relation to easily enable band-width limit in case of flooding
> and level of encryption and user access relations.

There is not need to store offers in files to get that functionality.

> Offers could then be auto-linked to some public www-data directory relation
> instantly or at some specific time every day, twice a day via cron, so spam
> and irrelevant offers could be censored before they're auto-added.


That is my humble option.  Anyway you are free to develop your proposed design 
and show to this mailing list the result. I am sure we will choose the best 
solution.