Re: Recomended front ends?

From: Andrew Kerber <andrew(dot)kerber(at)gmail(dot)com>
To: Tim Clarke <tim(dot)clarke(at)minerva(dot)info>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Recomended front ends?
Date: 2019-08-08 18:35:10
Message-ID: CAJvnOJaWrJVEPg-8sSTxKhJ1k2VOabdfTs0hMrGx4pZ2UfhSSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Aug 8, 2019 at 1:30 PM Tim Clarke <tim(dot)clarke(at)minerva(dot)info> wrote:

> On 08/08/2019 17:55, Stuart McGraw wrote:
> >
> > I would be a little cautious about Django. Last time I checked,
> > like many other web frameworks, it treats the database as just another
> > component, one that provides data persistence for it, and consequently
> > imposes its own constraints the schemas it will work with. Specifically
> > IIRC it insists that tables have a single-column primary keys. If the
> > client's existing database is already designed this way then that may
> > not be a problem but if it has composite PKs then another option may
> > be better.
> >
> > Flask is another relatively easy to use framework, can be used with or
> > without Sqlalchemy but doesn't have the wealth of addons available with
> > Django and being simpler requires more work to build the end application.
> > There are of course many other framework options (Bottle, Web2Py, etc)
> >
> > Although it's been a decade plus since I worked with Microsoft products
> > I had fairly good luck back then using Microsoft Access / VBA connected
> > to a Postgresql backend via ODBC. Even back then MS's frontend
> > development
> > tools were way more advanced and easy to use than anything available for
> > free in the Linux world. The downside was having to program in VBA but
> > things may be much better these days with .NET et.al.
>
>
> We tried Django without any pleasant results.
>
> I'd also caution using MS Access, we're desperate to get away from it.
> Sharing code has challenges and it is horribly aggressive with caching
> unless you use un-bound forms and write all the CRUD interface code
> yourself.
>
> Tim Clarke
>
>
>
> Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 |
> Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852 5803 1687 | Toronto: +1
> 647 503 2848
> Web: https://www.manifest.co.uk/
>
>
>
> Minerva Analytics Ltd - A Solactive Company
> 9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United
> Kingdom
>
> ________________________________
>
> Copyright: This e-mail may contain confidential or legally privileged
> information. If you are not the named addressee you must not use or
> disclose such information, instead please report it to admin(at)minerva(dot)info
> <mailto:admin(at)minerva(dot)info>
> Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd:
> Registered in England Number 11260966 & The Manifest Voting Agency Ltd:
> Registered in England Number 2920820 Registered Office at above address.
> Please Click Here https://www.manifest.co.uk/legal/ for further
> information.
>

You might look at Benthic SQLall.
--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bryn Llewellyn 2019-08-08 18:35:23 Re: Why must AUTOCOMMIT be ON to do txn control in plpgsql procedure?
Previous Message Tim Clarke 2019-08-08 18:30:26 Re: Recomended front ends?