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 <theophil...@gmail.com> wrote: > > > On 9 April 2018 at 07:39, Guyren Howe <guy...@gmail.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 > >