Re: Ubunto
Martin Gregorie wrote:
Arne Vajh=F8j wrote:
Martin Gregorie wrote:
Arne Vajh=F8j wrote:
I don't think Derby and PostgreSQL are alternatives.
You could use Derby for your development incl. unit test because it is
practically no install/config and PostgreSQL for your QA and
production for the reliability and performance.
Of course, but with PostgreSQL installed and running, the effort needed
to add a new project/database/call it what you will is probably the
same as it would be with Derby - and I don't need to learn another
database's SQL syntax quirks to do it.
But that is because you have have PostgreSQL installed and running.
True, but IIRC the initial install of PostgreSQL was pretty much a no-
brainer too.
The only non-straightforwardness I remember was due to me modifying the=
installation to move the physical database from the /var tree to /home
for system management reasons. I've arranged my system so that /home is=
in a separate partition and that /usr/local and /usr/java as well as all=
PostgreSQL and Apache related user data are there as well. This means
that, for a clean Linux install I can reformat everything on disk except=
the /home partition and know that nothing I care about will need to be
restored.
For development purposes, the default installation of Postgres works pretty=
well. For production purposes, as with any DBMS, the situation can be mor=
e complicated.
There are many goals you want a DBMS to achieve. Most people seem to talk =
about speed or ease of use as if reliability were taken for granted. First =
and foremost, the prime directive of any data store is to be reliable. Anc=
illary to that the management protocols for the system should not impede ke=
eping a system reliable. (The violation of this was my main complaint with=
MySQL. I don't know if they fixed it.) We do want the system to be of lo=
w footprint appropriate to the application domain. Fast enough for the pro=
ject usage. Scalable likewise.
Postgres and Derby both tend to win in another important area - standardnes=
s of the SQL dialect.
Postgres reaches down pretty far into the low end of scale, but obviously n=
ot quite as far as Derby. Conversely, Derby does quite well into higher sc=
ale, but obviously not quite as far as Postgres.
If you're doing a lot of enterprise or web work you should consider Postgre=
s strong contender. Even during development, it mixes well with the enter=
prise way of looking at things (layered and componentized). Porting a syst=
em from Postgres to, say, Oracle or DB2 turns out to be not so bad. Of cou=
rse no two RDBMSes speak the same dialect of SQL, but the transformations b=
etween 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 s=
emantics of a keyword to something rather different, as MySQL did with TIME=
STAMP.
That's just one scenario where one might find advantage to Postgres. Of co=
urse, the same arguments apply to the free versions of Oracle and DB2, to a=
point.
For desktop distribution Derby may well be the ideal solution. For a deskt=
op app needing more than desktop-scale data, perhaps a distributed DBMS arc=
hitecture - keep the local DB as a sort of edge cache for wide-area data.
I put forward this pie in the sky to point out that different systems fill =
different niches. I observe that between them, Derby and PostgreSQL cover =
the gamut of RDBMS needs and could even complement each other. Solid produ=
cts, open source, span the use case range: no need for me to hunt further. =
(This does not preclude reaching for non-RDBMS solutions.)
--
Lew