Newsgroup: it.comp.os.linux.development
Titolo: sviluppare gestionale x linux

Ciao a tutti.
sto valutando l'opportunità di sviluppare un gestionale che giri sotto 
linux.
La necessità è quella di gestire anagrafica e abbonamenti di un centro 
sportivo (quini corsi frequentati, frequenza, scadenze.. )
il sistema deve poi interfacciarsi tramite seriale con un lettore di 
badge.
premetto che sviluppare tale applicazione per win è una cavolata, l'unica 
cosa che mi frena è il discorso licenze. Il sw è free e non mi piace 
l'idea che per usarlo il centro debba acquistare licenze varie.
il problema però è che in linux ho sviluppato pochissimo e non conosco 
ebentuali ambienti RAD o se esistono formati per DB simili a MDB di 
access come "target" e funzionalità.
In sintesi come mi oriento? devo avere un server sql? devo sviluppare 
tutto in C oppure esistono RAD? Python potrebbe essere una valida scelta?
grazie a tutti per l'aiuto :)
ah, pensavo di sviluppare il tutto usando mandrake o debian
Davide

 tutto in C oppure esistono RAD? Python potrebbe essere una valida scelta?
imho se vuoi fare in fretta: 
gambas.sf.net
 + mysql .
-- 
Il denaro e' la madre di tutti i mali, e l'uomo ha bisogno della madre.

 tutto in C oppure esistono RAD? Python potrebbe essere una valida scelta?
Secondo me la cosa piu` veloce, soprattutto se conosci gia` python, e` di
usare python + glade + sqlite
Se invece il progetto e` grossino vai su un motore db come mysql o
postgres.
Bye.

 postgres.
non credo che il progetto sia condiderabile neppure tra i "medi"
al massimo avrà 1000-2000 entry anagrafiche e relative tabelle di storico
grazie per le dritte :)

 imho se vuoi fare in fretta: 
gambas.sf.net
 + mysql .
non conosco gambas.. corro a informarmi grazie :)

 al massimo avrà 1000-2000 entry anagrafiche e relative tabelle di storico
Io direi sqlite. Probabilmente te la caveresti anche con i bdb :)
Ma sqlite e` parecchio gagliardo ! :))
-- 
RiK0
Non credo negli schemi non vincenti.

 linux.
La piu' semplice e potente e' mysql+php. Hai interfacce grafiche in un
attimo e la potenza di gestire centinaia di utenti contemporaneamente anche
via web.
-- 
Ciao
Max
Che vitaccia!  Ci vorrebbe un cacciavite piu' grosso...
                -- Da it.hobby.umorismo

Io ti consiglio Gambas, poi come database puoi usare Sqlite o MySql. Io 
l'ho usato, ed è realmente notevole cosa ti permette di fare in poco 
tempo. Il linguaggio è il Basic. Ma è realmente semplice. Se poi vuoi, 
puoi usare Php+MySql, oppure Kylix della Borland, ma già stiamo sul 
difficile, perchè per l'uso dei database o compri la versione 
commerciale o usi librerie gratuite, ma le devi installare, e vedere se 
funzionano con la versione di Linux.
Franz

 via web.
beh, una dichiarazione simile andrebbe supportata da dimostrazione o 
messa in un tag <imho> </imho> :)

 Davide
Pui utilizzare le librerie qt e mysql. Ci puoi fare davvero di tutto e la
scrittura dell'applicazione è molto rapida e semplice.
Ciao
WildEagle

 anche via web.
mah nel mio caso è una feature che non mi serve
non avrò praticamente mai la necessità di accedere in multiutenza al DB
(nel caso peggiore ci saranno meno di 10 accessi simultanei....)
D

In data 30 Nov 2004 14:18:28 GMT, Davide C ha scritto:
[cut]
Ciao a tutti,
mi attacco al post per una curiosità: non ho visto risposte che riguardano
soluzioni del tipo client (con la GUI in GTK o altro) + accesso via odbc: è
una configurazione che è ignorata per qualche motivo ?
Thx
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
http://www.sgr.info
Email happyman69 (at) 
libero.it

Stefano 'HappyMan' ha scritto:
si ma ogni linguaggio ha una libreria che unifica le varie interfacce 
(dbi per perl/ruby/anche c, db-api per python, jdbc per java..)
Non che ciò sminuisca la  validità dell'approccio odbc, che è lo stesso, 
semplicemente al giorno d'oggi su linux non è granchè usato.

 anche in locale, proprio per poter decentralizzare in seguito.
Ma la comodità di odbc (io ne sono un fan, anche se sono conscio della
obsolescenza della tecnologia, grazie alla relativa facilità d'uso usando
direttamente le Win32 API in C/C++ senza impazzire con OLE/COM etc.) è un
concetto super partes: il fatto di separare la parte di accesso ai dati dal
codice che lo implementa mi è stato molto utile in passato, se si ha
l'accortezza di utilizzare il set comune ai diversi db di comandi sql.
Utilizzando fin dall'inizio le librerie messe a disposizione dai vari db
vendors (open source o meno che siano) ci si lega fin dall'inizio ad una
ben precisa piattaforma dbms.


 una configurazione che è ignorata per qualche motivo ?
Principalmente perche` ODBC in Linux non viene usato granche`, se non per
comunicazioni col mondo MS.
Di solito si preferisce, sia per motivi prestazionali che per poter
sfruttare tutte le caratteristiche di un DB, accedere direttamente al DB.
Che poi sia in locale o in remoto importa poco. Di solito si accede in TCP
anche in locale, proprio per poter decentralizzare in seguito.
Bye.

 ben precisa piattaforma dbms.
Il problema e` che appunto il set comune e` molto ristretto. Per esempio
MySQL (fino alla 3, la 4 non so) non supporta le sub-query, postgres ha un
suo sistema di gestione dei large object, ecc.
Trovo piu` comodo fare una parte backend a cui l'applicazione chiede "la
lista di quelle cose la`" che si arrangia, nel miglior modo possibile, a
comunicare al DB la richiesta e a far pervenire al frontend i dati
intabellati, o a cui dire "questi sono i dati, mettili nel db" e la
procedura si arrangia a metterli nelle tabelle giuste, verificando
l'integrita` e roba simile.
In questo modo si separa comunque la logica di gestione, e, se progettato
bene, basta riscrivere il backend di accesso al DB e non tutta
l'applicazione.
Un esempio banale (ma molto banale) e` un'applicazione che ho fatto un po'
di tempo fa con python+postgres. Poi mi sono accorto che avrei potuto
volerla usare sul palmare o sul notebook senza dover installare postgres,
e che i dati non erano tutto sto gran problema, e ho cambiato qualcosina
nel backend e convertita in sqlite in una mezza giornata.
So che con odbc ci avrei messo 30 secondi netti, ma comunque avrei avuto
una dipendenza extra (unixodbc) da mantenere.
Ci sono vantaggi e svantaggi in entrambe le soluzioni.
Bye.