Message-Id: <201804082237.w38Mb050004963@rs111.luxsci.com>
From: "g@luxsci.net" <g@luxsci.net>
Date: Sun, 08 Apr 2018 22:37:00 +0000
To: pgsql-general@postgresql.org
Reply-To: g@luxsci.net
Errors-To: g@luxsci.net
MIME-Version: 1.0
Subject: Re: Rationale for aversion to the central database?
Content-Type: multipart/mixed;
              boundary="------------------_Boundary_85677071.7481402";
              charset="utf-8"
Precedence: bulk

This is a multi-part message in MIME format.

If you cannot view the attachment(s), then your email client does not
support MIME.


--------------------_Boundary_85677071.7481402
Content-Type: multipart/alternative; boundary="-------------7657391.42080772"

---------------7657391.42080772
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

=C2=A0
=C2=A0
On April 8, 2018 02:40:46 pm PDT, "Guyren Howe" <guyren@gmail.com> wrote:
=C2=A0
I am a Rails developer at a medium-large size company. I=E2=80=99ve mostly=
=20
worked at smaller companies. I=E2=80=99ve some exposure to other web=20
development communities.

When it comes to databases, I have universally encountered the attitude=20
that one should treat the database as a dumb data bucket. There is a=20
*very* strong aversion to putting much of any business logic in the=20
database. I encounter substantial aversion to have multiple=20
applications access one database, or even the reverse: all abstraction=20
should be at the application layer.

My best theory is that these communities developed at a time when=20
Windows was more dominant, and just generally it was *significantly*=20
easier to use MySQL than Postgres for many, particularly new,=20
developers. And it is pretty reasonable to adopt an aversion to=20
sophisticated use of the database in that case.

This attitude has just continued to today, even as many of them have=20
switched to Postgres.

This is only a hypothesis. I am now officially researching the issue. I=20
would be grateful for any wisdom from this community.

Aside: it is rare to find a situation in life or anywhere where one=20
widely adopted thing is worse in *every way* than another thing, but=20
this certainly was and largely still continues to be the case when one=20
compares MySQL and Postgres. So why do folks continue to use MySQL? I=20
find this mystifying.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hi there. This issue is close to my heart and I'm with you.=C2=A0 I am=20
however very comfortable with using psql and PL/pgSQL and I am very=20
opinionated.
I feel *very* strongly that a database that actually matters and where=20
RI is critical, i.e., any PG db I handle, should make sense on its own=20
and be *highly* usable on its own. It should not be dependent on some=20
particular external application code to use it or make sense of things.=20
It follows that I think nonintuituve exceptions/gotchas should be=20
*clear* at a db level, likely using functions to encapsulate that=20
information.

Sure, PL/pgSQL may possibly be slow at some things like doing lots of=20
bigint math, but I would probably use C and ECPG for the appropriate=20
cases.
Not a large percentage of programmers these days know how fast db tasks=20
can be because they are used to working with relatively slow tools and=20
frameworks. ( Yes, typical Python.)

I am also highly mystified by the dumbstore approach and frankly, I=20
think that folks should KNOW their tools better. Not knowing how to use=20
your database effectively typically results in unnecessary and often=20
very convoluted application code, from my experience.

I keep hearing about db portability but I have yet to see cases where=20
db logic was an issue. But to be honest, I haven't seen many migrations=20
at all. Why? Because I think that it rarely ever happens. If I had to=20
do it, I sure as heck hope that the=C2=A0 db was "clean" and understandable=
=20
without
having to review some probably awful app. code. Why would anyone=20
migrate *away* from PG anyway? :)

One advantage to using logic and functions in=C2=A0 the db is that you can=
=20
fix things immediately without having to make new application builds.=20
That in itself is a huge advantage, IMO.

Cheers,
-g


---------------7657391.42080772
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML>
<HTML>
<HEAD><meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8"></HEAD>
<BODY style=3D"padding:5px; line-height: 1.3em; font-size: 13px; color: #33=
3; background-color: #FFF; font-family: Arial, Helvetica, sans-serif">
&nbsp;<br />
&nbsp;
<div style=3D"padding:3px 0 3px 0;border-top:1px solid #DDD; border-bottom:=
 1px solid #DDD;margin:3px 0 3px 0">On April 8, 2018 02:40:46 pm PDT, &quot=
;Guyren Howe&quot; &lt;guyren@gmail.com&gt; wrote:</div>
&nbsp;

<div name=3D"messageBodySection">I am a Rails developer at a medium-large s=
ize company. I&rsquo;ve mostly worked at smaller companies. I&rsquo;ve some=
 exposure to other web development communities.<br />
<br />
When it comes to databases, I have universally encountered the attitude tha=
t one should treat the database as a dumb data bucket. There is a *very* st=
rong aversion to putting much of any business logic in the database. I enco=
unter substantial aversion to have multiple applications access one databas=
e, or even the reverse: all abstraction should be at the application layer.=
<br />
<br />
My best theory is that these communities developed at a time when Windows w=
as more dominant, and just generally it was *significantly* easier to use M=
ySQL than Postgres for many, particularly new, developers. And it is pretty=
 reasonable to adopt an aversion to sophisticated use of the database in th=
at case.<br />
<br />
This attitude has just continued to today, even as many of them have switch=
ed to Postgres.<br />
<br />
This is only a hypothesis. I am now officially researching the issue. I wou=
ld be grateful for any wisdom from this community.<br />
<br />
<br />
Aside: it is rare to find a situation in life or anywhere where one widely =
adopted thing is worse in *every way* than another thing, but this certainl=
y was and largely still continues to be the case when one compares MySQL an=
d Postgres. So why do folks continue to use MySQL? I find this mystifying.<=
br />
<br />
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />
<br />
Hi there. This issue is close to my heart and I&#39;m with you.&nbsp; I am =
however very comfortable with using psql and PL/pgSQL and I am very opinion=
ated.<br />
I feel *very* strongly that a database that actually matters and where RI i=
s critical, i.e., any PG db I handle, should make sense on its own and be *=
highly* usable on its own. It should not be dependent on some particular ex=
ternal application code to use it or make sense of things. It follows that =
I think nonintuituve exceptions/gotchas should be *clear* at a db level, li=
kely using functions to encapsulate that information.<br />
<br />
Sure, PL/pgSQL may possibly be slow at some things like doing lots of bigin=
t math, but I would probably use C and ECPG for the appropriate cases.<br />
Not a large percentage of programmers these days know how fast db tasks can=
 be because they are used to working with relatively slow tools and framewo=
rks. ( Yes, typical Python.)<br />
<br />
I am also highly mystified by the dumbstore approach and frankly, I think t=
hat folks should KNOW their tools better. Not knowing how to use your datab=
ase effectively typically results in unnecessary and often very convoluted =
application code, from my experience.<br />
<br />
<br />
I keep hearing about db portability but I have yet to see cases where db lo=
gic was an issue. But to be honest, I haven&#39;t seen many migrations at a=
ll. Why? Because I think that it rarely ever happens. If I had to do it, I =
sure as heck hope that the&nbsp; db was &quot;clean&quot; and understandabl=
e without<br />
having to review some probably awful app. code. Why would anyone migrate *a=
way* from PG anyway? :)<br />
<br />
One advantage to using logic and functions in&nbsp; the db is that you can =
fix things immediately without having to make new application builds. That =
in itself is a huge advantage, IMO.<br />
<br />
Cheers,<br />
-g</div>

</BODY>
</HTML>


---------------7657391.42080772--


--------------------_Boundary_85677071.7481402--