Re: Rationale for aversion to the central database?

 
 
On April 28, 2018 11:18:02 am PDT, "Peter J. Holzer" <hjp-pgsql(at)hjp(dot)at> wrote:

On 2018-04-28 09:54:27 -0500, Steven Lembark wrote:
> On Sat, 28 Apr 2018 08:02:21 +0200
> "Peter J. Holzer" <hjp-pgsql(at)hjp(dot)at> wrote:
>
> > On 2018-04-27 22:52:39 +0000, g(at)luxsci(dot)net wrote:
> > > Perhaps I'm extreme. In my ideal world, developers might not even
> > > know table names! I'm kidding ,sorta... 
> >
> > If they don't know the table names, how can they write those stored
> > procedures?
>
> One of the main reasons DBA's need to be pigs. Much spaghetti can be
> avoided in ORM frameworks with well-designed views.

Apparently my remark was too short (and perhaps with too little context)
to be clear.

As I understood g(at)luxsci(dot)net, they were arguing for writing lots of
stored procedures so that developers wouldn't even have to know the
table names (they would just call the procedures) [Although I now see
that it was somebody else who proposed that as the only interface].

But those stored procedures don't write themselves. Somebody has to
write them and a person who writes code is called a developer. So there
needs to be at least one developer who knows the table names - the
developer of the stored procedures. And that developer should better be
good - API design is hard, and if you take away SQL from your fellow
developers you should give them something better (for the task at hand),
not something worse.

===

Yes, sorry, I meant application developers. Well, actually I meant
developers who only look at the db through an ORM and who like it that
way. At my current position, the ones called "developers" all use
Django, and they practically never look at ( let alone interact with)
the db using psql. Forget about writing and using pgsql functions.
There are no DBAs or database developers. I am trying to change this
culture a bit but I may give up soon. Tragic, really, given the mostly
terrible performance that they get with naive Django code. Some of
these developers have even gone so far as to proclaim that PG is too
slow ( they didn't even configure it !) for their "big" data, which
really aren't big, and move on to something like ES, which they really
don't need. For example, they have code that could benefit from simple
FTS operations, and instead of taking seconds or minutes, could be done
in milliseconds. Or perhaps they could not execute certain queries for
user interfaces quickly
enough with their Django code so they think that they need ES for those
queries. So now they have to manage and design their ES
implementations, activities which frankly should _not_ be taken
lighlty, and manage their data in the PG db which they eventually come
back to for at least some sane data integrity. Now they have to perform
very long and convoluted processes to keep both in sync. Ouch. Know
your tools!

But there is no all or nothing, as others have pointed out. Some things
are better done and more easily managed outside of the DB, at least for
me.
For example, I tried doing lots of bigint math in pgsql and I moved to
external C code for that.
That C code still called tried and true pgsql convenience functions for
getting at the correct data however, and these were the same functions
that my Java code used for other activities.

Gerry