Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9758

Re: Ubunto

Show all headers | View raw

On Sun, 06 Nov 2011 17:13:49 -0800, Lew wrote:

> For development purposes, the default installation of Postgres works
> pretty well.  For production purposes, as with any DBMS, the situation
> can be more complicated.
>
PostgreSQL itself can be shifted about fairly easily: the inflexibility 
was in the SYSVinit daemon management script it uses which, at least on 
RedHat Fedora systems up to the F12 release,  could only be reconfigured 
by editing the script because it ignored the convention of stashing 
configurable values in /etc/sysconfig. They fixed this for F13 - just in 
time to change things again when F15 introduced the systemd service 
management system.

> Postgres and Derby both tend to win in another important area -
> standardness of the SQL dialect.
>
Agreed. Does anything apart from MySQL insist on using auto-incrementing 
variables where the rest of the DB world mostly uses sequences? I don't 
really see the point given that you almost always want to know the value 
that was assigned (particularly if the field is in a prime key) and this 
forces you to read a row immediately after it was inserted.
 
> If you're doing a lot of enterprise or web work you should consider
> Postgres  strong contender.  Even during development, it mixes well with
> the enterprise way of looking at things (layered and componentized).
>
I'm still very impressed with it, not least for the way it keeps its 
filing system tidy and the DB stats updated with next to no management 
effort apart from making backups and the periodic need to restore from 
the backup after a major version upgrade.

> Porting a system from Postgres to, say, Oracle or DB2 turns out to be
> not so bad.  Of course no two RDBMSes speak the same dialect of SQL, but
> the transformations between the big guns seem to be mostly mechanical -
> Oracle uses VARCHAR2 for VARCHAR, for example.  It's harder when a
> system decides to reinvent the semantics of a keyword to something
> rather different, as MySQL did with TIMESTAMP.
>
The only major Postgres anomaly, that I've noticed anyway, is its use of 
a BYTEA where other DBMS would use a CLOB.

> For desktop distribution Derby may well be the ideal solution.  For a
> desktop app needing more than desktop-scale data, perhaps a distributed
> DBMS architecture - keep the local DB as a sort of edge cache for
> wide-area data.
>
Derby is very much on my radar: I just haven't yet found a round tuit or 
a good reason to use Derby in place of PostgreSQL.

Have you tried using it as a small central DBMS, i.e. not run as an 
integral part of an application? If so, are there any obvious gotchas or 
performance issues with running it that way?
 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Ubunto Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 15:47 -0500
  Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-06 22:49 +0000
    Re: Ubunto Lew <lewbloch@gmail.com> - 2011-11-06 17:13 -0800
      Re: Ubunto Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-07 23:49 +0000
        Re: Ubunto markspace <-@.> - 2011-11-07 21:07 -0800

csiph-web