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 <tshel...@gmail.com> wrote: > > On Tue, 27 Jun 2023 at 07:08, Guyren Howe <guy...@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 <htf...@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 <guy...@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.kla...@aklaver.com>, >> wrote: >> >> On 6/26/23 16:48, B M wrote: >> >> >> >> -- >> Adrian Klaver >> adrian.kla...@aklaver.com >> >> >> >> >> The 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 > >>
