Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Ubunto Date: Sun, 6 Nov 2011 17:13:49 -0800 (PST) Organization: http://groups.google.com Lines: 79 Message-ID: <5210608.1104.1320628429657.JavaMail.geo-discussion-forums@prms22> References: <4e9b8cd8$0$282$14726298@news.sunsite.dk> <4eb6f24f$0$295$14726298@news.sunsite.dk> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 173.164.137.214 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1320629221 29043 127.0.0.1 (7 Nov 2011 01:27:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 7 Nov 2011 01:27:01 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.164.137.214; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9717 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. >>=20 >> 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.=20 >=20 > The only non-straightforwardness I remember was due to me modifying the= =20 > installation to move the physical database from the /var tree to /home=20 > for system management reasons. I've arranged my system so that /home is= =20 > in a separate partition and that /usr/local and /usr/java as well as all= =20 > PostgreSQL and Apache related user data are there as well. This means=20 > that, for a clean Linux install I can reformat everything on disk except= =20 > the /home partition and know that nothing I care about will need to be=20 > 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. =20 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.) --=20 Lew