Date: Mon, 9 Apr 2018 16:04:32 +0200
From: "Peter J. Holzer" <hjp-pgsql@hjp.at>
To: pgsql-general@lists.postgresql.org
Subject: Re: Rationale for aversion to the central database?
Message-ID: <20180409140432.kcyqyi55s6444eov@hjp.at>
References: <7e56cc47-ae9c-43ee-9984-77df3a485d2e@Spark>
 <2020789773.14648.1523224664181.JavaMail.zimbra@opensysperu.com>
 <20180408233942.GF27724@tamriel.snowman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ifsi2bag6cjumdq5"
Content-Disposition: inline
In-Reply-To: <20180408233942.GF27724@tamriel.snowman.net>
User-Agent: NeoMutt/20170113 (1.7.2)
Precedence: bulk


--ifsi2bag6cjumdq5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-04-08 19:39:43 -0400, Stephen Frost wrote:
> * Alvaro Aguayo Garcia-Rada (aaguayo@opensysperu.com) wrote:
> > 1. Portability. Being tied to a single database engine is not always
> > a good idea. When you write business logic in database, you have to
> > write and maintain your store procedures for every database engine
> > you want to support. That can be really complicated, and will surely
> > take pretty much time, as programming languages for different
> > databases are very different from each other. And it's permanent:
> > Every time you make a change to a store procedure, you must make
> > that change for every supported database.
>=20
> The portability claim tends to be both a false one and often, when
> realized, results in a solution where you aren't using the database for
> anything complicated and you'd be better off with a much simpler data
> store.  You also don't actually offer any justification for the claim
> that being tied to a single database engine is not always a good idea-
> why is that?  With commercial databases it tends to be because you are
> at the behest of some very large commercial company- but that isn't an
> issue with PostgreSQL.

Many companies don't like to support multiple database engines. There is
the license issue, true, but having DBAs is even more important. If you
are an Oracle shop you have your Oracle DBAs, and they know how to make
backups (and how to restore them), how to monitor the database, how to
track down performance issues, etc. If some application needs MS-SQL or
PostgreSQL or MySQL, they won't have that expertise, so they will have
to be trained, or you need additional DBAs (maybe on a part-time or
support contract basis). So all other things being equal, companies will
prefer applications which work with databases they already use.

So if you are an application developer, it makes sense to develop your
application to work with several databases. It vastly expands your
potential clientele.

At least that was the situation 10 years ago. These days much software
is offered as a service. If the customer sees only a REST API and
doesn't have to host the database on their own servers, they won't care
about the RDBMS underneath.

        hp


--=20
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp@hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

--ifsi2bag6cjumdq5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlrLcuoACgkQ8g5IURL+
KF0fCxAApPcsPR1DDCbZWGmfTiTGxq4u+kRPkBbCkVvLe7kQdmhF+BvWMJbHWE2r
nZwPZmrL9DVLrv1mPD5fwo5UZOFdNyvQP3Azb6TaDGzCfz9hUxgIhe01SPtH+jRT
7tYkWdDLgeGGpf7aKZ8EZuYQBPlFiS9fCxx20NeBO5rAbG2fluONt6RlhqdTKGib
fR61oyNXdk4DsXxdzfmCggY5YDxdWkx225IWlytA0C80y071ulVOUS4tFffEwcGp
xgPquBJ7RFPnHPkwKKAeoXWg/sGV87mOT0zI4+QFGRzxvBCd3ZXxOy9uOdbUYhHH
7fSOaw1Wk/5giQiCRY1to9ySyru8l92VY+GIJjYruIeBONJO4+cq15vq88G1gwvg
O5aK3VmqXLvIqV1ZBw4tgIdepvu8AM6QV2KKo9VTvpax26rMhwzUG6TQON1b6x7u
nDUBkt5U8NHrogcmhGQhVQZ5CcqZG+kAsLTBuh9P2cfL/iFnavTTaoJYHg4LkHR2
D+SnmJUXLDIVEcF4wjJAnQcupmu+6k7C26J+gAHUJcwB/TXhecPU/eoLYLuw7l9u
Sx8lIZwyw0AwaxmrbC0Bj+aEj27uA3E8Z/ZIIXbGn7ckZbCLCmK7hfYBS9H0BvYr
1Ftyq7ajCt30dMETed7xy0Ax8gj5m9zB28NhixintioHmaUI2ZU=
=YbZ3
-----END PGP SIGNATURE-----

--ifsi2bag6cjumdq5--