From: | Avin Kavish <avin(at)baseboard(dot)ai> |
---|---|
To: | Tony Shelver <tshelver(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Large scale reliable software system |
Date: | 2023-06-27 12:15:12 |
Message-ID: | CAN5h1oQBydyT6RKhyxRKb=F1QCfpX-FiPFnoQNGXmRhiYjvL7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com> wrote:
>
> On Tue, 27 Jun 2023 at 07:08, Guyren Howe <guyren(at)gmail(dot)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(at)gmail(dot)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(at)gmail(dot)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(dot)klaver(at)aklaver(dot)com>,
>> wrote:
>>
>> On 6/26/23 16:48, B M wrote:
>>
>>
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)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
>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2023-06-27 12:47:44 | Re: Helping planner to chose sequential scan when it improves performance |
Previous Message | Karsten Hilbert | 2023-06-27 12:07:35 | Aw: When will trusted PL/Python be supported? |