Re: Rationale for aversion to the central database? - Mailing list pgsql-general

 
 

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@hjp.at> wrote:
>
> > On 2018-04-27 22:52:39 +0000, g@luxsci.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@luxsci.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