Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f5I2k-0005id-Dz for pgsql-general@arkaria.postgresql.org; Sun, 08 Apr 2018 21:40:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f5I2j-0007dC-B8 for pgsql-general@arkaria.postgresql.org; Sun, 08 Apr 2018 21:40:09 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f5I2i-0007cr-Ti for pgsql-general@lists.postgresql.org; Sun, 08 Apr 2018 21:40:09 +0000 Received: from mail-ot0-x235.google.com ([2607:f8b0:4003:c0f::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f5I2g-00046Y-Jk for pgsql-general@postgresql.org; Sun, 08 Apr 2018 21:40:07 +0000 Received: by mail-ot0-x235.google.com with SMTP id d9-v6so4340647oth.10 for ; Sun, 08 Apr 2018 14:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version; bh=wNEKDD5rUb2ek362S1Ic2+ASe3fMyctOWsS5F4wL7bg=; b=Kv9kmG0LIOlqgnik3NgP0yjeW+13bXI4/PW5K3uDcBJP3Rlo/hFUva+YVBHgomjqdF Vs2iel8A0AAxxDNTze5Yv1IEg89OmYZ4uhw+wi3PVKh4ECFhF0//E97sY5qfAyEpjhpy NXis3Cs4pzAaFysFhqiO3sY1kdpkj6B6nPYuGbHl+VY+ehkhGfct5DYq4YQRZG7G2r12 WgsB2s/3OGaTlsIMgwULq1lpaLyJmoEaJWWzXOQJsmeq9EEwXj0bUnxl75hMsiavf1Tp kjP0w8H4Zf3kaTw5BgrYGcb8zYqOSMWCBpq6CSywKe1aBCMZ9/2bsZ5C4z9Yp8cjKetX Q6OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version; bh=wNEKDD5rUb2ek362S1Ic2+ASe3fMyctOWsS5F4wL7bg=; b=QT7RPSbUw30Qw4v5y3Ad6fmw8y9JUJNLxY2dVlMIaEDwR8B6OhmI7a7lx8cJfP6Jnu tRcLQRz1eY/Fq/lPDWsD/AyfHbJlmBA2IAwxcaBtj+1gN2qyJCr8+19HhmO5+aXjCJzA cDokyw3O7EUKkHLlnsyN246gsFnVBKVeU6vXDBPztEEveZTtlHd+AGVaz7f4h0Ez/DCQ 2jopZjkej+/qT7v+xLn2Ch98pLItqYzKTGpFEe8gcWPyr+TB2S9uLk9LRnhlHLwRW4PC AVo62ovwZF2jK58zdOCmuhMjomUl7Sz4PvHjRKbADBnO3qFp1IyR0cIMS753j5usOg/Q +xCg== X-Gm-Message-State: AElRT7HVMi05GzcMJSkZuLW1XXTrrA9RnPBDCXVSQJR0K+iTf0zRA3WO uxUOFS9LIEUH4IJ3arb5s7CS9yaR X-Google-Smtp-Source: AIpwx48gvuXKv4PgdqcXyIVSunkHuQHKWQs1jW4q0LbtckbnjYrlFlgHipN7D1XE3s90/qU79v9E+w== X-Received: by 2002:a9d:1194:: with SMTP id v20-v6mr20222474otf.323.1523223605156; Sun, 08 Apr 2018 14:40:05 -0700 (PDT) Received: from [2600:8801:8800:1a:88be:cab6:100::] ([2600:8801:8800:1a::e]) by smtp.gmail.com with ESMTPSA id 98-v6sm8604579otv.37.2018.04.08.14.40.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Apr 2018 14:40:04 -0700 (PDT) Date: Sun, 8 Apr 2018 14:39:49 -0700 From: Guyren Howe To: PostgreSQL General Message-ID: <7e56cc47-ae9c-43ee-9984-77df3a485d2e@Spark> Subject: Rationale for aversion to the central database? X-Readdle-Message-ID: 7e56cc47-ae9c-43ee-9984-77df3a485d2e@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5aca8c33_140e0f76_e57" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --5aca8c33_140e0f76_e57 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I am a Rails developer at a medium-large size company. I=E2=80=99ve mostl= y worked at smaller companies. I=E2=80=99ve some exposure to other web de= velopment communities. When it comes to databases, I have universally encountered the attitude t= hat 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 applicat= ion 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 u= se MySQL than Postgres for many, particularly new, developers. And it is = pretty reasonable to adopt an aversion to sophisticated use of the databa= se in that case. This attitude has just continued to today, even as many of them have swit= ched to Postgres. This is only a hypothesis. I am now officially researching the issue. I w= ould be grateful for any wisdom from this community. Aside: it is rare to find a situation in life or anywhere where one widel= y adopted thing is worse in *every way* than another thing, but this cert= ainly was and largely still continues to be the case when one compares My= SQL and Postgres. So why do folks continue to use MySQL=3F I find this my= stifying. --5aca8c33_140e0f76_e57 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I am a Rails developer at a medium-l= arge size company. I=E2=80=99ve mostly worked at smaller companies. I=E2=80= =99ve some exposure to other web development communities.

When it comes to databases, I have universally encountered the attitude t= hat 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 applicat= ion 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 u= se MySQL than Postgres for many, particularly new, developers. And it is = pretty reasonable to adopt an aversion to sophisticated use of the databa= se in that case.

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

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


Aside: it is rare to find a situation in life or anywhere where one widel= y adopted thing is worse in *every way* than another thing, but this cert= ainly was and largely still continues to be the case when one compares My= SQL and Postgres. So why do folks continue to use MySQL=3F I find this my= stifying.
--5aca8c33_140e0f76_e57--