Re: Rationale for aversion to the central database?

Tim, I'm sorry if I sound like a cheerleader, but boy did you nail this. I
would basically say exactly the same thing, just not as well.

On Sun, Apr 8, 2018 at 9:37 PM, Tim Cross <theophilusx(at)gmail(dot)com> wrote:

>
>
> On 9 April 2018 at 07:39, 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.
>>
>
> It is interesting looking at many of the responses to this thread. I see a
> lot at each extreme - either put lots of stuff inthe database or use the
> database as just a 'dumb' store and put everything in the application code.
>
> I think the real solution is somewhere in the middle. I've lost count of
> the number of applications where the application code is jumping through
> all sorts of hoops to do basic data operations which would be far better
> handled in the database and can easily be done using just ANSI SQL (so is
> portable). It drives me crazy when people tell me the database is slow when
> they are doing 'select * from table' and then filtering and sorting the
> data in their application. Applications should take advantage of what the
> database does well. Unfortunately, I see far too many developers who are
> uncomfortable with SQL, don't know how to structure their queries
> efficiently (lots of nested sub queries etc, cartesian joins etc).
>
> At the other extreme is those who tend to put almost everything in the
> database - including business policy and business 'rules' which are
> probably better categorised as current business strategy. First, I think it
> is nearly always a mistake to try and enforce business policy with
> technology. Policies change too often and should be dealt with via
> administrative measures. Technology can certainly be used to raise alerts
> regarding policy breeches, but should not be used to enforce policies.
> Likewise, some business rules are more akin to strategies than being actual
> static rules and can change with little notice, rhyme or reason. These
> probably should not be 'hard coded' into the database. Other rules are more
> stable and unlikely to ever change and are likely good candidates for being
> encoded in the database as either functions or constraints.
>
> I do feel that often the big problem is with management who fail to
> understand the time and effort needed to develop a good data model.
> Developers are put under pressure to deliver functionality and as long as
> it looks correct at the interface level, all is good. Little thought is
> really put into long term maintenance or performance. From a developer
> perspective, time put into becoming an expert in React, Angular, Node,
> Python etc is probably going to earn them more bonus points than time spent
> on developing skills in defining good data models or understanding of the
> power/functionality of the underlying database engine. Of course, this does
> tend to be short sighted as a good data model will tend to make it easier
> to add/enhance an application and understanding your database system will
> make changes and enhancements less daunting.
>
> For me, the sign of a good developer is one who is able to get the balance
> right. They understand the strengths and weaknesses of ALL the components
> involved and are able to select the technology mix which suits the problem
> domain and are able to get the right balance between business
> responsiveness to change and long term maintenance/viability.
> Unfortunately, such developers are rare, so it will usually mean there are
> a team of people with different skills and what will matter is how well
> they are able to work together as a team and come up with an architecture
> which satisfies the business requirements.
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>