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.'
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? |