On 8/7/19 2:38 PM, Rich Shepard wrote:
> On Wed, 7 Aug 2019, Igor Korot wrote:
>
>> On top of what already been said - make sure that the product you are
>> about to start working on will have its requirements clear and concise.
>
> This is a critical process that needs to be developed in depth. One
> criterion that will guide your choice of UI is whether the database will be
> accessed only on the LAN or also remotely. For the former, consider using
> Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based
> application using Django.
>
> HTH,
>
> Rich
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.