Qui ti devo dare un pochino di torto, leo.
Come vengono memorizzati i dati ha importanza, eccome!
E' probabile che tu non abbia mai avuto a che fare con le date, per esempio... E' vero che se tratti tutto come una stringa, il problema non si pone, ma non si pone solo se la tua applicazione è l'unica che gestisce il db. Metti conto, sempre per fare un esempio, di trattare dati provenienti da fonti diverse, magari fuori dell'ambito nazionale, oppure di fare calcoli particolari du numeri, senza doversi preoccupare di qual'è, e se è presente, il carattere separatore dei decimali, oppure (e ritorno al problema degli spazi), di avere stringhe altamente variabili (addirittura documenti o foto) in quantità enormi, come te la cavi?
Certo, la cosa è risolvibile, come in tutte le cose a livello software, ma devi mettere mano al codice per forza.
Quando parliamo di un DBMS (o RDBMS), a livello server, non parliamo solo di un motore, bensì di un applicazione server a tutti gli effetti, che è indipendente da cosa e da chi ci stà attaccato.
Come ho già menzionato, ci sono, e ci sono stati, già svariati motori simili a sqlite; non dico che bisogna buttarli al secchio, solo che hanno dei limiti, e grossi se confrontati a server evoluti.
Il discorso vero stà nel fatto che la scelta di usare un semplice motore, piuttosto di un server evoluto, è dipendente sempre e solo da cosa si vuole ottenere e quali sono le risorse a disposizione. E' ovvio che per costruirmi un'agendina, non vado a comprare un Oracle Enteprise (anche se la scelta potrebbe anche dipendere da altri fattori).
Un discorso più realistico, sarebbe quello di dire: "bene, ora voglio imparare come funziona e come installare e pilotare un DBMS; metto su un'applicazioncina, e provo a far funzionare il tutto, allo scopo di imparare". In questo caso, la scelta ha uno scopo che prescinde dalle risorse impiegate: imparare!
Sempre come ho già più volte scritto, sqlite lo paragono ad un database scritto su file di testo, con in più la possibilità di interfacciarmi tramite il linguaggio SQL che, rivolto a sqlite, ha un set molto limitato.
Qualcuno ha mai usato i trigger, o le stored-procedures ? La possibilità di avere strumenti di questo tipo ha enormi vantaggi, e questo sqlite, almeno per ora, ne è privo. Non sò se l'autore di sqlite implemeterà mai cose del genere, e personalmente ho molti dubbi in proposito, perchè si scontrerebbe con sistemi già belli che evoluti e funzionanti, a meno che non lo faccia anche per puro divertimento, o per imparare lui stesso.
Questo è il mio pensiero... (almeno per stasera, domani vedremo... :-) )
Comunque, per ritornare alla richiesta iniziale del nostro amico, voglio dare un paio di suggerimenti, visti i suoi dubbi, e il voler prevedere eventalità future:
1) imparare ad usare MySQL, sistema molto veloce con, però, parecchie features non proprio standard e abbastanza personali; da tener conto che però se l'è comprata la SUN, e che la SUN è stata ora acquistata dalla Oracle, per cui non si sà quale futuro abbia...
2) imaparare ad usare PostegreSQL, sistema molto robusto, open-source, ma di molto simile ad Oracle, anche se ad oggi non ha tutte le stesse caratteristiche; il sistema è ormai integrato in tutte le distro, e già di base funziona subito, anche senza modificare alcuna configurazione.
In tutti e due i casi, dopo aver letto almeno qualcosina a riguardo, c'è un buon numero di strumenti per l'amministrazione del server e la gestione dei database, per cui non vedo grandi difficolta a metter in piedi anche una semplice "agendina". Fatto il primo passo, il resto e semplice...
