Re: Large scale reliable software system - Mailing list pgsql-general
Well, seeing as postgres isn't designed to serve http requests or to run general purpose code that doesn't involve databases, which you can express elegantly in python, to answer OP's question - my vote is on the original answer - Django. It's got everything out of the box - authentication. file storage. etc etc.
Once you get the application running you can enhance the database as necessary.
On Tue, Jun 27, 2023 at 4:19 PM Tony Shelver <tshelver@gmail.com> wrote:
On Tue, 27 Jun 2023 at 07:08, Guyren Howe <guyren@gmail.com> wrote:Correct. It’s a tragically wrong piece of folk wisdom that’s pretty general across web development communities.On Jun 26, 2023, at 21:32, Michael Nolan <htfoot@gmail.com> wrote:It's not just Ruby, dumb databases are preferred in projects like
WordPress, Drupal and Joomla, too.
Now, if it's because they're used to using MySQL, well maybe that's
not so hard to understand. :-)
On Mon, Jun 26, 2023 at 8:05 PM Guyren Howe <guyren@gmail.com> wrote:
This is a reasonable answer, but I want to offer a caveat.
Likely because of the influence of the originator of Ruby on Rails, it is close to holy writ in the web development community that the database must be treated as a dumb data bucket and all business logic must be implemented in the Ruby or Python or whatever back end code.
This heuristic is nearly always mostly wrong.
Guyren G Howe
On Jun 26, 2023 at 17:48 -0700, Adrian Klaver <adrian.klaver@aklaver.com>, wrote:
On 6/26/23 16:48, B M wrote:
--
Adrian Klaver
adrian.klaver@aklaver.comThe accepted front-end developer wisdom of treating the DB as a dumb data store works under conditions, for example the DB will never be accessed from a different ORM / framework, and where the performance attributes of using an ORM with 'standard' datastructures are acceptable.The moment you need to plug in something like reporting tools, or access from a different system / API / framework / language / ORM or whatever, the approach not having rules / views / procedures / whatever built into the database falls apart.Other things to consider are performance / load / overhead: we have one system that involves processing through large amounts of data for reports / queries. Shipping all that back through the ORM / db interface (ODBC / JDBC / psycopg2 / whatever for resolution / filtering on the front end application where SQL / procedures / views could do that in the DB and just ship back the required data seems counterproductive.Tony Shelver
pgsql-general by date: