Re: Rationale for aversion to the central database?

 
 
On April 8, 2018 02:40:46 pm PDT, "Guyren Howe" <guyren(at)gmail(dot)com> wrote:
 
I am a Rails developer at a medium-large size company. I’ve mostly
worked at smaller companies. I’ve some exposure to other web
development communities.

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

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

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

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

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 certainly was and largely still continues to be the case when one
compares MySQL and Postgres. So why do folks continue to use MySQL? I
find this mystifying.

===============

Hi there. This issue is close to my heart and I'm with you.  I am
however very comfortable with using psql and PL/pgSQL and I am very
opinionated.
I feel *very* strongly that a database that actually matters and where
RI is 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 external 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, likely using functions to encapsulate that
information.

Sure, PL/pgSQL may possibly be slow at some things like doing lots of
bigint math, but I would probably use C and ECPG for the appropriate
cases.
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
frameworks. ( Yes, typical Python.)

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

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

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

Cheers,
-g