# Consiglio su semplice database

## topper_harley

Ho bisogno di creare un semplice database con queste caratteristiche:

* deve gestire un semplice inventario

* deve essere di semplice amministrazione (lo faccio a tempo perso)

* deve essere facilmente gestibile dall'utente anche da macchine windows (un interfaccia web sarebbe la cosa migliore)

* deve avere una soluzione di backup semplice e facilmente trasferibile (il server che voglio utilizzare e' un vecchio laptop che non durera' in eterno)

* sarebbe meglio se gli strumenti fossero in portage o se fossero disponibili degli ebuild

Premesso che so molto poco di database mi servirebbe sapere quali strumenti utilizzare:

* il motore del database

* il sistema per amministrarlo (phpmyadmin o simili)

* l'interfaccia utente

Su quest'ultimo punto proprio non so da dove partire, ovvero se creare delle pagine php a mano (preferirei non farlo), oppure se esiste qualche strumento o framework che faccia questo al posto mio.

Sono aperto a tutte le soluzioni, grazie per l'aiuto.

----------

## MeMyselfAndI

mysql o postgres ... entrambi con tutto quello che ti serve.

----------

## topper_harley

 *MeMyselfAndI wrote:*   

> mysql o postgres ... entrambi con tutto quello che ti serve.

 

Beh... come dovrei implementare l'inerfaccia utente?

Mi spiego meglio, l'utente finale deve gestire l'inventario aggiungendo beni, modificandone le quantita' ecc., come mi consigli di creare questi form?

----------

## .:deadhead:.

imho o trovi uno strumento chiavi in mano pensato per fare inventario, oppure è meglio che te lo fai a mano. 

Che sia mysql(su innodb, l'integrità referenziale non la barattare) o postgres poco cambia.

Per il come il php è un linguaggio molto semplice per sviluppare su cui trovi molto materiale. 

Certo è che se sei proprio a digiuno il fare tutto ex novo ti porterà via del tempo: meglio cercar cose già fatte.

----------

## topper_harley

 *.:deadhead:. wrote:*   

> imho o trovi uno strumento chiavi in mano pensato per fare inventario, oppure è meglio che te lo fai a mano. 
> 
> Che sia mysql(su innodb, l'integrità referenziale non la barattare) o postgres poco cambia.

 

Ok, ho sentito parlare bene di entrambi, quindi credo che come dici tu non faccia molta differenza.

 *Quote:*   

> Per il come il php è un linguaggio molto semplice per sviluppare su cui trovi molto materiale.

 

Infatti credo che faro' qualcosa del genere. Un server gentoo con lighttpd (o cherokee) e qualche pagina in php.  

 *Quote:*   

> Certo è che se sei proprio a digiuno il fare tutto ex novo ti porterà via del tempo: meglio cercar cose già fatte.

 

Tipo qualche erp? Qualche consiglio?

Ad ogni modo la prossima settimana sono all'estero e avro' parecchio tempo per documentarmi. Sapete consigliarmi qualche buona lettura (anche cartacea) riguardante php e i database?

----------

## .:deadhead:.

gli articoli e le guide su phpnews.it sono ben fatte.

----------

## Ic3M4n

se vuoi sbatterci la testa, e soprattutto conosci già il python dai un'occhio a django, quel poco che ho fatto mi è venuto molto naturale. l'approccio è simile a rails che però utilizza ruby.

----------

## Kernel78

Se la base utenti non è sterminata consiglio caldamente sqlite, non c'è nessun server che gira (e nessuna configurazione da fare) e il database sta in un unico file che puoi copiare tranquillamente per backupparlo.

----------

## Peach

 *Kernel78 wrote:*   

> Se la base utenti non è sterminata consiglio caldamente sqlite, non c'è nessun server che gira (e nessuna configurazione da fare) e il database sta in un unico file che puoi copiare tranquillamente per backupparlo.

 

beh a sto punto faccio l'avvocato del diavolo e se le tue richieste non sono grosse e vuoi avere massima portabilità e flessibilità ti consiglio XML, lo puoi vedere come un database strutturato i cui vincoli relazionali sono espliciti: usa un motore di query interno che si chiama Xpath molto potente. puoi anche fare join tra più "db" (ovvero fogli xml) tramite rdf o cose ancora più potenti con owl... 

lo manipoli con qualsiasi programma, e la strutturazione del DOM è comune a tutti.

----------

## randomaze

 *Peach wrote:*   

> beh a sto punto faccio l'avvocato del diavolo e se le tue richieste non sono grosse e vuoi avere massima portabilità e flessibilità ti consiglio XML, lo puoi vedere come un database strutturato i cui vincoli relazionali sono espliciti: usa un motore di query interno che si chiama Xpath molto potente. puoi anche fare join tra più "db" (ovvero fogli xml) tramite rdf o cose ancora più potenti con owl... 
> 
> lo manipoli con qualsiasi programma, e la strutturazione del DOM è comune a tutti.

 

Permettimi di dubitare che xml offra le stesse performance di un sqlite/mysql/prostgres  :Rolling Eyes: 

----------

## Kernel78

 *randomaze wrote:*   

>  *Peach wrote:*   beh a sto punto faccio l'avvocato del diavolo e se le tue richieste non sono grosse e vuoi avere massima portabilità e flessibilità ti consiglio XML, lo puoi vedere come un database strutturato i cui vincoli relazionali sono espliciti: usa un motore di query interno che si chiama Xpath molto potente. puoi anche fare join tra più "db" (ovvero fogli xml) tramite rdf o cose ancora più potenti con owl... 
> 
> lo manipoli con qualsiasi programma, e la strutturazione del DOM è comune a tutti. 
> 
> Permettimi di dubitare che xml offra le stesse performance di un sqlite/mysql/prostgres 

 

Non avrà di sicuro le stesse performance ma la premessa di Peach era di non avere richieste grosse e indubbiamente su piccoli volumi di dati la differenza di prestazioni è trascurabile lasciando a XML il vantaggio della portabilità estrema.

A mio parere è un po' da masochisti ma è carina come idea.

----------

## Peach

 *Kernel78 wrote:*   

> Non avrà di sicuro le stesse performance ma la premessa di Peach era di non avere richieste grosse e indubbiamente su piccoli volumi di dati la differenza di prestazioni è trascurabile lasciando a XML il vantaggio della portabilità estrema.
> 
> A mio parere è un po' da masochisti ma è carina come idea.

 

non ci trovo niente di male, in fondo le mie premesse sono chiare.

e poi se devo dirla tutta, se qui si vogliono presentare le possibilità, non capisco perché escludere questa  :Smile: 

Gli strumenti per maneggiare xml ci sono e sinceramente da mia esperienza non sono più complessi di quelli per maneggiare i dati di un db.

----------

## Kernel78

 *Peach wrote:*   

> non ci trovo niente di male, in fondo le mie premesse sono chiare.

 

era randomaze che dubitava, io ho chiarito che rispettando le tue premesse la soluzione fosse tecnicamente valida

----------

## djinnZ

 *Peach wrote:*   

> Gli strumenti per maneggiare xml ci sono e sinceramente da mia esperienza non sono più complessi di quelli per maneggiare i dati di un db.

 

Mi accodo con una domandina: la base quanto deve essere piccola?

Per una anagrafica finale di ~100.000 record personali, suddivisi in gruppi di massimo di ~5.000 (in realtà mi serve rispettivamente per 200 e 800 ma tanto vale pensare in grande) vale? Con quale base (vorrei evitare linguaggi interpretati)?

In generale c'è qualche strumento grafico wysywyg semplice semplice? Ho smesso di programmare per causa della gestione dell'input e dell'output a video ed in stampa (pigrizia).

----------

## Peach

 *Kernel78 wrote:*   

>  *Peach wrote:*   non ci trovo niente di male, in fondo le mie premesse sono chiare. 
> 
> era randomaze che dubitava, io ho chiarito che rispettando le tue premesse la soluzione fosse tecnicamente valida

 

e io ho sbagliato a quotare  :Embarassed: 

 *djinnZ wrote:*   

>  *Peach wrote:*   Gli strumenti per maneggiare xml ci sono e sinceramente da mia esperienza non sono più complessi di quelli per maneggiare i dati di un db. 
> 
> Mi accodo con una domandina: la base quanto deve essere piccola?
> 
> Per una anagrafica finale di ~100.000 record personali, suddivisi in gruppi di massimo di ~5.000 (in realtà mi serve rispettivamente per 200 e 800 ma tanto vale pensare in grande) vale? Con quale base (vorrei evitare linguaggi interpretati)?

 

purtroppo non posso darti dei dati precisi.

Posso però fornirti degli spunti, riflessioni personali e analisi fatte da altri: 

database binario e file di testo xml hanno i loro pro e i loro contro.

- xml ha la capacità di esprimere vincoli relazionali e strutture molto complesse in maniera chiara e human readeable (il cosiddetto schema xml, composto di elementi, attributi e testo). Tutto ciò è immagazzinato in formato utf-8 su un file di testo su un file system e quindi su dei dischi.

- un db binario è invece ottimizzato proprio dal lato di accesso e lettura dei singoli dati in particolar modo quando sono coinvolte numerose join (generalizzazione di una questione ben più complessa), d'altro canto la struttura non è esplicita, è fondamentalmente bidimensionale e legato all'engine usato.

Queste due forme di rappresentazione non si escludono a vicenda, direi piuttosto che sono complementari: infatti dipende molto da quello che ci devi fare, dalla portabilità dei dati e dal numero di applicazioni che ci devono accedere, per non parlare della riusabilità del codice e la possibilità di svincolare o meno i dati dalla loro rappresentazione.

Un buon progettista dovrebbe poter valutare queste proprietà in base alle esigenze.

Ci sono quindi degli articoli che mi sono capitati a portata di mano e che vi linko qui per completezza giusto per citarne un paio:

XML Performance and size (2005)

Apache XML Performance FAQ

RE: XML Versus Relational Database

in particolar modo nell'ultimo link si fa esplicito riferimento all'implementazione dei linguaggi che accedono alla struttura dati e devo dire che, avendo avuto modo di lavorarci, c'è stato un grande sforzo in questo senso negli ultimi anni, dal punto di vista di ottimizzazione di memoria, engine di rendering e via dicendo.

Ci sarebbe inoltre da dire che la suite XML fornisce una famiglia ben più vasta di quello che si crede per la manipolazione dei dati: trasformatori da un formato all'altro, o ad altri (XSLT, XSL-FO, etc), sistemi di query (XQuery, XPath, SparQL, etc), sistemi semantici e ontologici su vocabolari xml (RDF, OWL, etc)

 *djinnZ wrote:*   

> In generale c'è qualche strumento grafico wysywyg semplice semplice? Ho smesso di programmare per causa della gestione dell'input e dell'output a video ed in stampa (pigrizia).

 

per lavorare su xml e per realizzare degli schemi xml avevo usato tempo fa oxygen, ma è a pagamento.

penso cmq che una query su google aiuti.

spero di essere stato sufficientemente conciso senza però aver lasciato intendere cose sbagliate.

----------

## djinnZ

Per fare i programmi intendevo, le famigerate "maschere di imput" (quanto odio stò termine), e non solo per xml, per lo schema faccio prima con un editor di testo e per il resto basta un xslt che trasformi in html.

----------

## Peach

 *djinnZ wrote:*   

> Per fare i programmi intendevo, le famigerate "maschere di imput" (quanto odio stò termine), e non solo per xml, per lo schema faccio prima con un editor di testo e per il resto basta un xslt che trasformi in html.

 

beh come con i db il problema è lo stesso: fare il programma ad hoc per trattare i tuoi dati, validarli ed inserirli

oppure usare XForms, che sebbene sia ancora una Candidate Raccomendation, è molto valido ed usabile.

----------

## .:deadhead:.

Farò l'avvocato dell'avvocato del diavolo, ma se già sqlite ha dei limiti, usare xml come base dati è imho un'estrema forzatura, pur considerando tutte i se e i distinguo fatti dal Peach . 

L'uso di tecnologie ben affermate e standard come un dbms meglio se ACID compliant  non richiede risorse esagerate sia umane che sistemistiche che unito all'uso di SQL offre una rapida soluzione ad un problema, tecnologie su cui, tra l'altro, è facile trovar supporto, cosa che non si può dire delle sopracitate tecnologie. 

Un articolo che  potrebbe interessare a topper_harley

----------

## Kernel78

 *.:deadhead:. wrote:*   

> Farò l'avvocato dell'avvocato del diavolo, ma se già sqlite ha dei limiti, usare xml come base dati è imho un'estrema forzatura, pur considerando tutte i se e i distinguo fatti dal Peach . 
> 
> 

 

Ovviamente sqlite ha dei limiti ma a mio parere (e come si deduce anche dal commento che ha ricevuto) il buon vecchio Pettenò non ha mostrato molta esperienza di DB, si lamentava della lentezza del comando INSERT e aveva ignorato le TRANSACTION che con estrema probabilità lo avrebbero aiutato moltissimo (provate con sqlite a vedere quanto impiega un ciclo di 10000 insert e poi mettete lo stesso ciclo in una transaction e vedrete la differenza abissale).

L'altro problema che sollevava era che scriveva un file temporaneo in /var/tmp (su disco) invece che in /tmp (in tmpfs), a questo si potrebbe ovviare:

- mettendo /var/tmp in tmpfs

- modificando il percorso nel sorgente (non penso che ci avrebbe messo più di 10 minuti)

Non sono veri problemi quelli, al massimo avrebbe più senso lamentarsi delle funzionalità mancanti al massimo ...

Scusate per la divagazione.

----------

## topper_harley

Grazie a tutti per l'aiuto.

Mi sono documentato un po' e mi sono fatto un idea migliore di quello che mi serve. Tralasciando le questioni troppo tecniche ho pensato a una soluzione con:

database: mysql

framework: rails

server: lighttpd

La scelta di rails e' data dal fatto che lo trovo molto ben organizzato e documentato, ho comprato questo libro che tra l'altro ha un ampio tutorial su come creare un'applicazione simile alla mia.

Per quanto riguarda il database capisco tutti i dubbi e le preplessita' che avete postato in questa discussione, ma quasi tutta la documentazione che si trova in giro su rails fa riferimento a database mysql, e sinceramente non ho voglia di sbattermi piu' di tanto.

Le versioni piu' recenti usano come databse di default sqlite, ma eventualmente sara' per la prossima  :Smile: 

Quanto al server attualmente sto sviluppando l'applicazione con il server integrato di ruby (WEBrick) che e' molto comodo da usare in fase di sviluppo. Una volta terminato passero' a lighttpd che gia' uso su un altro server e col quale non ho problemi particolari.

----------

## Peach

 *.:deadhead:. wrote:*   

> ma se già sqlite ha dei limiti, usare xml come base dati è imho un'estrema forzatura .

 

scusa ma mi sfugge nesso della tua frase. anzi direi che è una estrema forzatura. Ho cercato di mettere a chiare lettere che db relazionali e xml sono due modi di affrontare una stessa problematica, ma dire che sono la stessa cosa e metterli in relazione in base alla features che uno ha implementato e dare per scontato che l'altro non ne abbia senza fare nessuna citazione mi sembra un pelo eccessivo.

Per continuare con quello che dici: 

 *.:deadhead:. wrote:*   

> L'uso di tecnologie ben affermate e standard come un dbms meglio se ACID compliant non richiede risorse esagerate sia umane che sistemistiche che unito all'uso di SQL offre una rapida soluzione ad un problema, tecnologie su cui, tra l'altro, è facile trovar supporto, cosa che non si può dire delle sopracitate tecnologie.

 

non capisco ancora il nesso. 

xml non è uno standard? 

non è affermato (dopo 10 anni)?

non lo usano?

non può essere considerata una soluzione del problema?

non c'è supporto su xml?

Che senso ha parlare delle features di SQL/dbms (di cui sono ben conscio e che sono state continuamente ripetute fin'ora anche da me), per dire che - praticamente - XML fa schifo?

Insomma, non stiamo mica facendo una guerra di religione qui! Un pelo di obiettività dovrebbe aiutarci ad ampliare e a capire le possibilità che ci fornisce il mondo circostante, perché sennò, più che avvocato del diavolo, fai la figura del "Bellarmino"  :Wink: 

----------

