Re: Rationale for aversion to the central database?

On 04/08/2018 02:39 PM, Guyren Howe 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.

In general I see it as a case of people working where they are
comfortable. So folks that understand and like SQL do the heavy lifting
there and use application logic to just work with the output of the
database business logic. Folks that are comfortable with a language
other then SQL use that language to do the business logic and see the
database as just the dumb data store you refer to. The rise of
frameworks over databases has also contributed to this in my opinion.
Mostly because they encourage the notion that there is such a thing as
universal SQL that operates independent of the underlying database.
While it is possible it usually leads to a very simple SQL model that
can work over multiple database engines. So again you end up with the
database as a data bucket.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com