Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <kg87jq$kfd$1@ger.gmane.org>
References: <mailman.2180.1361463791.2939.python-list@python.org> <20130222164513.9377097f0cf2add2a6d16204@gmx.net> <kg87jq$kfd$1@ger.gmane.org>
Date: Sat, 23 Feb 2013 03:57:46 +1100
Subject: Re: PyQT app accessible over network?
From: Alec Taylor <alec.taylor6@gmail.com>
To: Monte Milanuk <memilanuk@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2284.1361552276.2939.python-list@python.org>
Lines: 51
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:39591

Monte: I noticed you mentioned web2py; that would be my recommendation.

You also mention different features being available to different
users; perfect use-case for web2py's built-in RBAC.

Scalability: Go with Postgres, MySQL; or considering how much data
you're talking about, even SQLite would be a close enough fit!

Another advantage of sticking to the web that hasn't been mentioned so
far is agnostic interoperability.

E.g.: you can CRUD on your TV (e.g.: if it runs Android); or on your
phone (e.g.: if you use twitter-bootstrap; which web2py comes with out
of the box; but is usable in any framework)

On Sat, Feb 23, 2013 at 3:50 AM, Monte Milanuk <memilanuk@gmail.com> wrote:
> Yes, I am looking at a database-centric application.  I know that the
> 'larger' databases such as PostgreSQL, MySQL, etc. would not have any
> problem handling that small amount of traffic.
>
> My concern is that using postgres or mysql for this would be akin to using a
> sledgehammer to swat a fly, when sqlite could most likely handle the load
> well enough (I think) since the handful of people doing data entry would
> rarely (if ever) be trying to write to the same record. That would be the
> whole point of having multiple people doing data entry in this situation -
> each one handling a different competitors entry form or submitted scores.
>
> My other reason for wanting one 'central' app is that there are various
> functions (setting up the tournament, closing registration, editing scores,
> finalizing results) that I really *don't* want the satellite/client apps to
> be able to do.  My personal view is that sort of thing needs to be handled
> from one point, by one person (the match director or chief stats officer,
> depending on the size of the event).
>
> That is why I was looking at things in terms of having one central app that
> handles the database, whether locally via sqlite or postgres or whatever,
> but have the clients access go through that main application in order to
> ensure that all they have is a limited set of CRUD abilities for competitor
> registration and entering scores.
>
> Thanks for the links... some of those I was already aware of (Camelot, Dabo)
> but some of the others are new (QtAlchemy, etc).  Should make for
> interesting reading!
>
>
> Thanks,
>
> Monte
>
> --
> http://mail.python.org/mailman/listinfo/python-list