> I was just curios as to wether you can install Postgres on e-smith?
Sure. Haven't done it personally on e-smith, but I can't see any reason why
it would be a problem. I have RH 6.2 machines running both and they do not
conflict, just load up the RPM and it should be fine (do a backup of your
server first, of course).
> Also why choose mysql over postgres???
The basic, in a nutshell response to the difference is this:
MySQL is simple, and to the point. Most will argue (and I would agree),
MySQL is faster and less resource intensive.
PostgrSQL is much more robust, transactional features (ability to rollback
changes, etc.) being the most notable. With that, comes a loss in
performance and it can be a drag on the system.
Each has it's place, and I use both. Two quick examples:
- I have a system that captures performance and error metrics (Syslog-like
data) from about 10,000 devices in the field. They create about 300,000
records in a day. I originally had this on Postgres, and just the posting
process took almost a day (medium speed machine) and sometimes more than a
day. Bascially, I had trouble keeping up with the flow of data. None of
this data was "critical" (I could lose it and not die). I switched it over
to MySQL and the posting process took only a couple hours, and query
response was order of magnitudes better. Eliminating all the
rollback/integrity features really sped the process up.
- I have another db that contains device configuration and registration
data. Super-critical, if I lose data, I lose touch with that customer(s).
Integrity is key, volume is low (about 200 changes/additions per day).
Postgres is the perfect solution for this, and to the best of my knowledge,
I have never lost any data (knock on wood). To be honest, if I did it all
again, I would probably do even this on MySQL, but I am happy the way it is
too.
The uses e-smith has for a db basically fall into the range where
performance is key, the systems are often low-end Pentiums, and integrity is
not paramount (and the volume is such that it is not likely to be an
issue). Also, as volume is fairly low, good coding will minimize situations
where integrity is compromised (multiple processes accessing/updating the
same data concurrently).
Beyond that, it is a "Chevy vs. Ford" argument, and a matter of personal
choice. Either one could be used and do the trick just fine. I personally
agree with the choice of MySQL for this app.
JP
