[Python] Gestionale fatto in casa

[enrico franchi]

2009/4/14 salvatore monaco <salvatore.monaco a gmail.com>:

> io uso mysql ma postgres non e' da meno come potenza scalabilità e
> performance
> ma qualsiasi sia la scelta che tu voglia fare a livello di database sappi
> che devi padroneggiare tutto lo scibbile del db per poter avere il meglio.

Non esageriamo. Capisco dire che bisogna padroneggiare i db, su questo
sono d'accordo. Ma per me padroneggiare lo scibile dei db ha un significato
un po' eccessivo.

Tipicamente la distribuzione fisica dei dati su disco (organizzazione a livello
di cilindri, per dire), le strategie implementative per gestire
failures hardware
e ricorstruire a partire da dati corrotti, implementare indici, multi-indici,
implementare in modo efficiente b-tree, hash-tables, obdd, scrivere
un'ottimizzatore
per query SQL (o in generale ottimizzare espressioni dell'algebra
relazionale), la
conseguenze ottimizzazione dei piani per l'esecuzione delle query
la memorizzazione efficiente di righe, implementazione di varie
politiche di undo/redo,
e colonne su disco a seconda dell'efficienza che si vuole ottenere,
magari in ambiente
distribuito e parallelo... beh, tutta sta roba fa parte dello scibile
dei db, ma direi che
e' abbastanza sovradimensionata per scrivere un gestionale, visto che
interessa a chi
scrive un DBMS e non chi lo usa.

Qualche fondamento e' utile per capire le questioni di efficienza (per
dire sapere come
si implementano gli indici puo' essere molto utile per progettarli in
modo efficiente lato
utente), ma in generale potrebbe essere un overkill per un gestionale
con Django.

> per quanto riguarda GUi io prediliggo per adesso il web con django ma se
> devi sviluppare e scegliere un toolkit grafico vale la stessa regola per i
> db

Si, anche io suggerirei un gestionale GUI based nella maggior parte dei casi.
Testare le web-ui se non esageri e' piu' facile che testare le UI
classiche, IMHO.

> sono tutti strumenti accellenti ma bisogna conoscerli con profondità per
> averne il meglio.
> ho visto cose fatte con tkinter da paura....

Quoto, ovviamente. Tkinter e' solo un po' bruttarello di default (e
IMHO rispetto
certe librerie come Cocoa e Qt *rimane* bruttino), ma pre il resto fa
il suo mestiere.

> usa da subito un software per il versionamento del codice csv o svn vanno
> benissimo

CVS io lo schiverei ormai. SVN fa il suo mestiere.
Ultimamente sono innamoratissimo di Perforce.
Per stare su roba open, io userei mercurial.

> parti da delle specifiche funzionali , carta e penna e diagrammi di flusso
> sono molto piu' importanti della scelta del db o del toolkit grafico
> e non dimenticare che la forza di un buon progetto e' la struttura del Db
> pensa bene a come organizzare i dati tabelle, le stored procedures e i
> trigger per far fare al db il lavoro che altrimenti faresti fare a
> python(l'ho imparato con ORACLE, plSQL a manetta) .

Qui invece sono abbastanza in disaccordo. Premessa: io sono un forte
fautore di metodi agili di sviluppo. Sono fortemente convinto che il
big-design up front sia un ottimo modo per avere un cattivo progetto.
Questo e' diverso da dire che *non* ci deve essere design, eh.

Non so comunque se sia il caso di insistere qui sulle metodologie di sviluppo.
OP potrebbe essere ferrato in questo e semplicemente non avere esperienza
con lo sviluppo Python, per cui fare una discussione su XP potrebbe essere
solo fuori luogo. <http://www.extremeprogramming.org/>

Non solo, molte stored procedures sono IMHO evitabili, *oggi*. MySQL ha un
supporto limitatissimo, Postgre lo ha migliore, ma rimane sempre un PITA
rispetto a scrivere le cose in Python. Hai un certo hit in termini di
efficienza,
ma e' difficile imbattercisi in un gestionale come quello di OP. Direi anche
impossibile, visto e considerato che addirittura non sconsiglierei un ORM.
Le SP ti vincolano ad un singolo DB. Potrebbe non essere *necessariamente*
la scelta migliore. Io partirei con l'idea di non usarle affatto e la
cambierei dopo
avere comprovato che semplificano *considerabilmente* le cose. Vedo sotto
che parti da una logica di AS400, e questo spiega la tua visione. E non lo dico
in senso negativo. Dico solo che cambiando in modo cosi' radicale la piattaforma
(qui parliamo di Python + piccolo db su un server win/linux), certe
scelte potrebbero
essere molto diverse.
Nota che debuggare una SP in Oracle e' ben piu' facile che farlo su
Postgre o su
MySQL.


Per il suo progetto io addirittura sarei del parere che il db e' quasi
un dettaglio
implementativo sottostante il modello ad oggetti. Questo e' in contrasto con la
classica visione del problema, ma e' un punto di vista sempre piu'
diffuso, specie
in questi ambiti.





-- 
-enrico