Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Ubunto Date: Mon, 7 Nov 2011 23:49:15 +0000 (UTC) Organization: UK Free Software Network Lines: 60 Message-ID: References: <4e9b8cd8$0$282$14726298@news.sunsite.dk> <4eb6f24f$0$295$14726298@news.sunsite.dk> <5210608.1104.1320628429657.JavaMail.geo-discussion-forums@prms22> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1320709755 4705 84.45.235.129 (7 Nov 2011 23:49:15 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Mon, 7 Nov 2011 23:49:15 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9758 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 |