Newsgroup: it.lavoro.informatica
Titolo: nuovo progetto Opensource (GPL)

Salve a tutti,
volevo sapere se qualcuno in questo NG può essere interessato a 
sviluppare un progetto opensource con l'obbiettivo (per ora) di 
usare/studiare il database di oggetti Db4o.
Sto facendo una programma gestionale, (ordini/vendite, ecc., insomma la 
solita roba), le cui caratteristiche sono all'incirca queste:
1. struttura interamente ad oggetti, e senza SQL (grazie al Db4o);
2. implementazione semplice (l'obbiettivo è che ognuno se lo possa 
personalizzare a suo uso e consumo), con uso pesante di generics, 
componenti, query compilate e codice compatto e facile da leggere;
3. gestione completa del ciclo acquisti/ordini/vendite;
4. in ambiente .NET 2, scritto con C# e VS 2005 (anche versione 
express-gratuita), ma compatibile con Linux/Mono (per ora una potenzialità).
Mi interessa qualunque tipo di aiuto, anche da persone non 
particolarmente esperte di C#/.Net.
Ovviamente mi interessa (e molto) anche l'opinione di chi non possa dare 
una mano. Ad es.: l'esistenza di un programma simile potrebbe esservi 
d'aiuto nel lavoro (intendo come base per le vostre implementazioni, 
escluso quindi lo studio delle tecniche)? Oppure conoscete un sito 
italiano di progetti simili (tipo SourceForge, per intenderci) dove si 
possa discutere meglio la cosa?
Grazie a tutti,
Giuseppe Simone Aielli
--
gsai...@ieee.org


http://csvtosql.sf.net
La legge e' uguale per tutti. -- Anonimo

 
Io ti posso dire che mi sta semplicemente entusiasmando!!! Non trovo le 
parole... ti cambia la vita.
1. niente mapping OR;
2. niente più SQL, ma query compilate che scrivi nel tuo linguaggio;
3. totalmente trasversale: Java/Mono/MS;
4. ha una struttura semplice, si impara in fretta e, per quello che fa è 
facile da usare (in proporzione!!).
Secondo test fatti da loro arriva ad essere anche 40 volte più veloce 
dell'accoppiata Hibernate/Mysql, ma credo che sia molto discutibile. Una 
cosa è sicura, lo stanno usando in tanti, il che significa che funziona 
bene e che ha velocità paragonabili ai prodotti concorrenti.
Ma è LA TUA di velocità che cambia. Se ci pensi solo le query 
compile-safe e l'assenza di mapping OR da sole tagliano tempo di 
sivulppo e bachi di un ordine di grandezza! Immagina che, perfino 
l'aggiunta di campi e tabelle (li chiamo così di proposito) a 
posteriori, è TRASPERENTE per la tua applicazione!
Leggi il tutorial, è fatto benissimo. E poi approfitta del progetto che 
ho proposto nella precedente per "studiare". Lo sto facendo per quello.
Saluti,
gsa
PS. considerato il tono entusiastico che ho usato, è bene precisare che 
io non ho nulla a che fare con Db40 inc. Beninteso!

Sono interessato.
Ho un amico, il mio PM, che è stà studiando a fondo i cosiddetti
"oggetti persistenti" e ha coinvolto un pò anche me in questa ricerca.
Dunque, il principale difetto di db4o è che si tratta di un database
puramente OO, molto veloce ma perde molta della flessibilita di un
RDMS. Diversi articoli sono stati scritti in merito alla "morte" dei
database puramente ad oggetti. Poi è GPL e non LGPL.
Troverai molto interessante Nhibernate. LGPL, sviluppato in C#,
permette di usare oggetti persistenti su diversi database relazionali.
Io ho comiciato a guardarlo nel (pochissimo) tempo libero, è
straordinario.
Comunque nel C# 3.0 (progetto DLINQ) queste cose saranno integrate nel
Framework:
[Table(Name="Customers")]
public class Customer
{
    [Column (Id=true)]
    public string CustomerID;
}
oppure
var q =
    from c in db.Customers
    where c.Region == null
    select c.ContactName;
foreach (var c in q) Console.WriteLine(c);
Ho anche parecchi link molto interessanti ma non su questo portatile :(
in cui si parla delle differenza tra i vari prodotti. E' un argomento
interessante, fammi sapere cosa hai in mente.

 
** Grazie del tuo post, è molto interessante. Uso nHibernate 
correntemente (ho usato anche Neo e iBatis) e cercavo una soluzione 
alternativa senza la complicazione del mapping OR, più semplice. 
Condivido la preoccupazione per il discorso GPL/LGPL, in quanto, come è 
ovvio, non tutti i progetti possono essere Opensource, ma in questo caso 
c'è la licenza commerciale.
Forse non immagini quanto è più semplice e lineare un progetto Db4o 
rispetto al corrispondente ORM (hibernate o altro).
E sono curioso di leggere quegli articoli cui accenni. In realtà non 
credo che la flessibilità sia un difetto dei db oggetti, secondo me è 
solo un problema commerciale.
Naturalmente non ci sono gli stessi strumenti (ad es. amministrazione, 
reporting, ecc.), ma è solo questione di tempo.
Sono invece i db relazionali, che sono anacronistici: non bastano righe 
tabelle e relazioni per descrivere il nostro mondo, e l'ORM è solo un 
compromesso per accontentare tutti. Non dimentichiamo che il mercato dei 
database è un mercato enorme e che vale un sacco di soldi.
Quanto all'approccio puro ad oggetti prova a guardare Matisse. E' ancora 
più interessante (ma costa). E c'è anche un ibrido che è un'idea 
fantastica (ma è ancora in prealfa), si chiama Raptor: salva gli oggetti 
nel db tradizionale.
A presto,
gsa
PS. quanto al progetto iniziale, si può anche fare un dual-engine 
(nHibernate + Db4O), se si trova gente. Altrimenti io vorrei proseguire 
con Db4o, per i motivi che ho detto. Quanto all'uso che si potrebbe fare 
del programma, venisse fuori qualcosa di utile, Db4o consente anche lo 
sviluppo in-house.

 tabelle e relazioni per descrivere il nostro mondo
Non entro nel merito della discussione o del progetto (ogni ricerca in nuove 
direzioni secondo me va incoraggiata), ma mi permetto di criticare la tua 
affermazione: i DB relazionali, in sé, non hanno nulla di sbagliato o 
limitante; semplicemente, sono stati proposti (e spesso considerati) come la 
soluzione a tutti i problemi di trattamento di dati, e questo ovviamente non 
è vero. Per molti usi però vanno benissimo, e sono assolutamente 
insuperabili; mi riferisco in particolare a tutte quelle situazione dove le 
tabelle sono ben definibili e le righe hanno tutte attributi molto simili, 
come ad esempio la classica contabilità bancaria: per dire che il 
correntista X ha 42 euro sul suo conto non serve affatto un database ad 
oggetti, e il modello "tabella - righe - colonne" descrive la situazione 
molto meglio di una qualsiasi gerarchia OO; ovviamente, se si parla di 
rappresentare in un database una gerarchia ad oggetti complessa, allora 
molto probabilmente un database OO ha più senso di uno relazionale, e 
l'errore è quello di voler usare un DB relazionale per forza, interponendo 
in mezzo un layer di adattamento che penalizza le prestazioni.
Prendi il caso di Microsoft: utilizza nei suoi prodotti due engine di 
archiviazione ben distinti, l'ESE di Exchange e Active Directory (OO) e 
quello di SQL Server (relazionale); questo perché SQL Server è un RDBMS, 
mentre AD ed Exhange di relazionale hanno ben poco, essendo architetture OO.
Quindi, per concludere, sono d'accordo con le tue critiche ai DB relazionali 
come panacea di tutti i mali, ma non generalizziamo troppo dicendo che non 
servono a nulla e che quello relazionale è un modello superato, please :-)
Massimo

Massimo ha scritto:

Massimo,
grazie di queste osservazioni. Concordo con te nel senso che non volevo 
"buttare a mare i database" così, di punto in bianco (dopo 12 anni di 
matrimonio). Al momento soffro un po' di Db4o-filia...
Volevo comunque riflettere con te sul fatto che una struttura di tabelle 
ben definita è ... quasi impossibile, visto che il mondo è troppo pieno 
di eccezioni.
Lo stesso esempio che hai fatto tu: ogni correntista è soggetto a 
condizioni differenti e la stessa colonna (o funzione) totale_qualcosa 
discende da regole differenti. Preleva i dati da campi che servono al 
correntista x e non servono a y, ecc. Ma soprattutto tutti questi 
dettagli devo gestirli io, mentre le regole (cioè la parte di 
informazione che non si può salvare nei DBMS) dovrebbe gestirsele il 
motore, una volta che io le ho definite. In questo senso le regole che 
si possono impostare in un dbms sono troppo elementari (integrità, 
dominio e trigger), e ti spaccano la logica dell'applicazione in due 
posti, cosa che poi si deve gestire.
Resta l'ovvia considerazione che, come prevedibile, in presenza di molti 
dati, le performance del db tradizionali sono ancora un punto a loro 
favore, mentre è meno ovvio il problema costituito dalla riluttanza di 
chiunque a cambiare paradigma, sia esso il cliente oppure lo stesso 
sviluppatore.
A presto,
gsa

 potenzialità).
Perché, visto il cammino intrapreso, non utilizzare SharpDevelop? Io sto 
utilizzando la beta della versione 2 ed è molto interessante.
-- 
Ciao!
Luca

Luca Menegotto ha scritto:

Per me è ok. L'ho usato per qualche tempo e ancora lo uso se devo 
tradurre vb<->c#. Tuttavia è molto comodo editare le classi direttamente 
dal relativo diagramma e viceversa, cosa che si può fare (facilmente) 
solo con VS2005. Senza contare l'edit/continue.
Ognuno dei contributori potrà utilizzare lo strumento che gli pare.
Ps. (forse lo sanno già tutti?): l'APress dà via gratis il libro degli 
autori di sharpdevelop (Dissecting a C# Application). Nel sito.

 solo con VS2005. Senza contare l'edit/continue.
Io non usavo SD per la cronica mancanza di debugger (era noioso 
utilizzare quello di .NET). Se non che, nella versione 2, hanno inserito 
proprio un bel debugger, con edit/continue e tante altre belle cosine. 
Certo, quache problema ancora c'è, ma è una beta 1!! :D
Invece, mi incuriosisce quel database a oggetti. Nei prossimi giorni, 
tempo permettendo, gli do un occhio.
-- 
Ciao!
Luca


http://csvtosql.sf.net
Uno che invece sui motori sa tutto e' Raul Torino. Si chiama Raul Torino
perche' viene da... Raul, un paesino in provincia di Torino. -- Francesco
Salvi

 delle tecniche)?
Scusami una omanda impertinente :-)
Ma come mai per un gestionale avresti deciso di usare un DB ad oggetti? Hai pensato a come si comportera' il sistema 
quando avrei immesso milioni di dati e sarai interessato, per esempio a fare ricerche complicate su ordini pregressi, 
sullo stato del magazzino, sulla storia di un cliente, etc etc? hai pensato a come implementare tutta la parte di 
analisi dei dati? Dico, alle performance, una volta che il sistema raggiungera' scale importanti?
In un progetto per cui ho lavorato diverso tempo fa avevano usato un DB ad oggetti in un gestionale, perche' era la 
moda, faceva fico, e noi eravamo i piu' fichi di tutti, per cui abbiamo fatto tutto ad oggetti. Ma quando dovevi andare 
a fare una query che su oracle o postgres si sarebbe risolta in 1/10 di secondo, dovevi fare delle contorsioni mentali 
inimmaginabili, e i tempi erano a malapena accettabili.
Per quanto ho visto, i DB ad oggetti, a meno che non migliorano un po' le tecnologie, vanno bene fino a quando navighi 
le relazioni, ma sono un suicidio quando vuoi andare a discriminare su relazioni fra oggetti, non appena le cardinalita' 
diventano un minimo elevate. E io penso che un gestionale ben fatto debba prevedere di poter essere usabile pure su 
grandi scale.
Facci caso, se vai sul sito della Versant (il DB ad oggetti piu' usato, almeno fino a  qualche anno fa...), non citano 
affatto l'impiego Versant in applicazioni getionali o roba che gli si avvicina.

 cambiare paradigma, sia esso il cliente oppure lo stesso sviluppatore.
Questo è poco ma sicuro.
Ma cambiare per forza paradigma non risolve necessariamente i problemi :-)
Massimo

 nel db tradizionale.
Conosco (Rapptor, con due "p" vero?), avevo cominciato a guardarlo e
sinceramente non ricordo perchè non l'ho più considerato ^^
Su db4o condivido le critiche che lo vedono in difficoltà a trattare
grosse moli di dati. Però a riguardo non ho benchmarks. E sinceramente
considero quello delle prestazioni un problema solo quando i tempi per
recuperare un set di dati diventano sensibilmente elevati.
Torno al lavoro e qui sono già perle se riesco mi fanno usare ADO.
a presto, fammi sapere che sono interessato (anche se il mio apporto
sarà minimo, ho poco tempo ed molto poca esperienza)

 affatto l'impiego Versant in applicazioni getionali o roba che gli si avvicina.
** Caro Principe,
nel post iniziale ho scritto "usare/studiare" Db4o. Inizialmente avevo 
scritto anche "piccolo progetto", ma poi ho levato il "piccolo" perchè 
faceva un poco "cazzatella" (e in effetti... chissà...). Non so perchè 
tu ed altri avete inteso che volevo gestire milioni di record, oppure un 
sistema critico (come quello di una banca).
Mentre i miei obbiettivi sono molto più modesti. La maggior parte delle 
situazioni nelle quali mi imbatto io l'unica cosa che conta davvero sono 
i costi di sviluppo ed in questo, ti assicuro, DB4O FOREVER!!!
Ti ringrazio comunque di aver condiviso con me la tua esperienza, e 
spero che continuerai ad essere dei nostri.
gsa

 
** Sognare non costa niente... Grazie per la tua disponibilità.

 tempo permettendo, gli do un occhio.
** Posso dirti due cose: leggi il tutorial, che è fatto benissimo (non 
come quello di nHibernate), oppure APPROFITTA di questo progetto per 
studiare. Al momento il codice è in uno stato ancora un po' pietoso, ma 
se hai pazienza...


http://csvtosql.sf.net
"Noi attori passiamo la vita a cercare di fare cio' per cui la gente normale
viene chiusa in manicomio." -- Jane Fonda

 Ti ringrazio comunque di aver condiviso con me la tua esperienza, e spero che continuerai ad essere dei nostri.
Ovvio che si' :-) 

 Ci daro' una occhiata ... sono veramente curioso.
** Appena posso rilascio qualcosa e faccio un nuovo post. Sarà una roba 
acerba, comunque...
