Framework e strumenti per applicazioni di database Python

Question

Ho iniziato a creare applicazioni per database aziendali quali finanza, inventario e altre applicazioni aziendali. Sto pensando di passare a Python. Quali sarebbero gli strumenti per iniziare al meglio. Avrei bisogno di master, moduli di transazione, elaborazione (back-end), rapporti e quel genere di cose. Il database sarebbe post-mandato o mysql. Siccome sono nuovo in Python, capisco che ho bisogno oltre a Python l'ORM e anche un framework. La mia applicazione non è correlata a un sito Web, ma potrebbe anche essere necessario eseguirla sul Web, se necessario.

Come scegliere la configurazione iniziale delle combinazioni di utensili?

Answer 1

Se fossi in te, vorrei iniziare con django.

Answer 2

Come Boudewijn Rempt ha scritto here, "per il modo più semplice per creare un'applicazione [[NON-web]] database, è possibile dare un'occhiata a PyQt". Ha scritto questo 6 anni fa, ma penso che sia perfettamente vero anche oggi. il modulo QtSql di pyqt4, in particolare, supporta MySQL, PostgreSQL e molti altri database.

Answer 3

Se l'applicazione deve funzionare sia sul desktop che sul Web in futuro, è possibile considerare la creazione di un'applicazione basata sul Web con un server distribuibile. Queste cose sono abbastanza facili da fare con Python sia in modi banali che in quelli più potenti come l'uso di Twisted.

Se solo il desktop è la tua direzione, allora come ha detto Alex, vai per PyQt. È davvero facile da usare e offre funzionalità GUI molto potenti con collegamenti DB versatili.

Come per il DB - quale siete abituati ad usare? Se sei, per esempio, un guru di MySQL, sarebbe prudente prima di tutto controllare i binding MySQL di Python. Per un ORM sicuramente provare SQLAlchemy.

Forse ulteriori dettagli nella domanda possono aiutare a fornire una risposta più completa.

---

Maggiori dettagli (per il tuo commento):

Se PostgreSQL è la tua direzione, Python ha PyGreSQL come vincolante. È open source, come Python stesso, quindi non dovresti avere problemi con le applicazioni a costo zero per l'utente. Per quanto Python sia la scelta giusta, penso che lo sia. Considera che molti siti Web potenti eseguono Python (YouTube, Reddit, persino Google per alcune applicazioni). Python viene anche utilizzato in numerose applicazioni ad alto volume come i sistemi di controllo del codice sorgente Mercurial e Bazaar e il mailman del gestore della mailing list.

Answer 4

solo FYI, per PyQT, il libro ha un capitolo 15 con Database, sembra buono. e il libro ha qualcosa con dati e vista ecc. Ho letto e penso che valga la pena il tuo tempo :)

Answer 5

Se fossi in te, probabilmente guarderei prima se una soluzione basata sul web basata su Django fa il trucco. Se ti serve un po 'di più, aggiungi jQuery al mix. Se fornisce troppo poche funzionalità, vai su PyQt. Se hai un sacco di applicazioni molto piccole, scegli un mix di tecnologie. Di seguito, trovi il mio (un po 'lungo) ragionamento per questa raccomandazione.

Webapp vs. applicazione desktop

Un anno fa, abbiamo avuto un business db e avevo bisogno di un front-end. Dovevamo decidere quale tecnologia utilizzare per il front-end.Abbiamo preso in considerazione:

1. PyQt
2. basata sul Web (cercare here per una panoramica di web frame-lavori per Python)

i vantaggi per PyQt dal nostro punto di vista:

• Esperienza C++ precedente con Qt da cui sapevamo che Qt è adatto per l'attività.
• Tutti gli strumenti necessari inclusi.
• Facile sviluppare clienti ricchi.

Abbiamo tuttavia deciso contro PyQt e per una soluzione basata sul Web. Ragioni erano:

• I requisiti per il front-end sono stati modesti e facile da fare all'interno di un browser (segnalazione per lo più, alcuni moduli per l'immissione di dati o l'esecuzione di funzioni).
• La distribuzione dell'applicazione (e nuove versioni, correzioni di errori, ecc.) è molto più semplice poiché tutto accade solo sul server in un ambiente controllato.
• Il controllo di accesso/autenticazione/diritti è "gratuito" poiché fa parte del server (nel nostro caso Apache utilizza l'autenticazione di Active Directory) e il browser, che è importante per noi.
• L'applicazione richiede comunque la connessione al server e non è necessario memorizzare nulla sul lato client.

In poche parole: ricco di funzioni front-end con un sacco di funzionalità in un ambiente di distribuzione controllata sono probabilmente più facile da implementare con Qt. Per i nostri front-end leggeri, una soluzione basata su server ci è sembrata migliore.

Quale framework web?

Ora che avevamo deciso una tecnologia, dovevamo scegliere un quadro. Abbiamo ricercato un po ', e guardato due alternative in dettaglio:

1. Django
2. Una pila di software costituito da CherryPy come dispatcher (per abbinare le richieste HTTP alla funzionalità e tutta la roba correlata), Mako come template libreria per generare pagine Web, SQLAlchemy come ORM e jQuery per la funzionalità lato client.

Abbiamo valutato le due alternative e alla fine abbiamo optato per la seconda. La decisione è stata dettata dai nostri requisiti di front end davvero "leggeri e leggeri" (un sacco di applicazioni molto piccole). Una pila di software - che possiamo mixare e abbinare secondo necessità - ci è sembrata migliore. Possiamo riutilizzare SQLAlchemy in situazioni in cui non abbiamo bisogno di un front-end Web, possiamo semplicemente utilizzare CherryPy senza una libreria di modelli e un ORM e così via. In molti altri casi, sceglierei comunque Django su questo stack.

Per riassumere:

• una grande, complessa applicazione -> PyQt
• una serie di relativily simile, straigtforward rapporti, forme, ecc, con un look-and-feel -> Django
• un insieme relativamente eterogeneo di cose che differiscono ampiamente nei requisiti e nella tecnologia o ri-utilizzo di alcune tecnologie utilizzate in altre circostanze -> mix di tecnologie come necessario

Answer 6

Dato che non mi piaceva nessuno dei quadri disponibili, ho deciso di scrivere qualcosa da solo. Forse vorresti dare un'occhiata allo Pylax. È costruito in GTK e utilizza Python incorporato per lo scripting. Il back-end è SQLite, per ora.