Newsgroup: it.comp.java
Titolo: Consiglio XML ,Database o Entrambi?

Salve io dovrei realizzare, un progetto J2EE
che dovrebbe essere strutturato in questo modo.
l'utente deve avere la possibilità di aggiungere a piacimento, campi
nella form del layout, deve poter firmare con firma elettronica il
documento e infine memorizzarlo.
in un primo momento avevo pensato ad una soluzione basata su DB ma
questo mi comportava l'impossibilità di far aggiungere al db campi in
modo dinamico, e cosa avrebbe firmato il cliente se nn c'erano file?
poi avevo pensato che la pesonalizzazione potevo fargliela io subito
prima dell'installazione ma così mi ritrovavo con ejb diversi e
sarebbe poi stato un problema quando dovevo manutenere il codice ed
inoltre per la firma stesso problema.
poi ho pensato di creare la struttura con un file xml il layout veniva
generato a partire da questo con xsl e per la firma potevo quindi
passare il file xml generato al parser di firma, il tutto poi veniva
memorizzato all'interno del db per poter essere rintracciato
successivamente in modo rapido, così quando l'utente cercava i dati
dal db anzichè interrogare il db per poi ricomporre il tutto ..tiravo
fuori solo il file con uno stream e lavoravo su quello.
Ma non credo che questa soluzione sia tanto "pulita" avete
suggerimenti?
Grazie anticipatamente 
Luigi

Guarda, purtroppo non conosco la tecnologia per la firma elettronica: puoi 
farmi un breve riassunto cosi' da capire meglio il problema?
XML sembra la soluzione ideale. Cmq non è necessario salvare i dati XML in 
un DB: crei un file XML unico (oppure con i link interni) e riprendi le 
informazioni dal di li'. 

La tecnologia per la firma elettronica si basa su un algoritmo per la
firma e quindi consiste nella cifratura, con la chiave privata del
sottoscrittore, dell'impronta del documento generazioni di chiavi
private/pubbliche. Il dispositivo di firma per essere riconosciuto deve
essere rilasciato da ente accreditato. In sostanza gli si passa un file
(doc, pdf, etc...) e il parser di firma lo trasforma in un file con
estensione diversa (p7qualcososa).
Il db mi sever perchè al file xml devono essere associati degli
allegati, che non è possibile salvare su file (quindi anche questi
memorizzati all'interno del db) inoltre la mole di file con il tempo
crescerebbe in maniera impressionante. Parliamo di 15.000 file /anno
quindi con un sistemadi indice basato su file le prestazioni si fanno
benedire, inoltre è + facile fare il backup dei dati.
Però la soluzione credo non sia proprio elegante.
Grazie per la risposta!

Ok.
In questo caso specifico che file passi al dispositivo di firma? Suppongo 
sia generato a partire dal DB... ma in che formato?
Quanto sarebbero grandi i file XML per ogni documento?
Per "allegati" intendi degli altri file allegati che non vengono firmati?
Mi viene in mente un'idea di questo tipo:
- nel database tieni traccia di tutti i documenti, del nome del file XML in 
cui sono contenuti i dati e del nome del file firmato
- all'interno del file XML indichi quali sono i file allegati allo stesso 

Potrebbe essere una buona soluzione, però...
al dispo di firma passo in quel caso il file xml da firmare (che è il
documento stesso)
Il file non viene generato da un db per il motivo che l'utente aggiunge
campi dinamici..(vedi primo post)
Per allegati intendo documenti che possono essere sia di tipo immagini
(molto grandi) e sia di tipo doc firmati anch'essi.
cmq i file xml posso assumere dimensioni ragguardevoli.
Quindi la tua soluzione se ho ben capito sfruterebbe il db solo come
indice dei file.
Ma mi sorge il dubbio che così il backup sia problematico, in quanto
nel momento del backup devo ricordarmi di salvare tutti i file e i loro
allegati, altrimenti rischio poi di invalidare il documento.
grazie ancora
Luigi

 crescerebbe in maniera impressionante. Parliamo di 15.000 file /anno
Sul mio portatile, un PiV non particolarmente perfomante, ho creato 10
milioni di file in una directory, e la ricerca per nome di uno qualsiasi
ci mette pochi msec. Qualsiasi moderno file system basato su btree - io
uso ReiserFS - č infitamente piů veloce di un database per questo tipo di
cose. 15000 file all'anno č praticamente zero, a meno che il server non
sia un pc con windows, e pure molto anziano! Per un lavoro di questo tipo
un onesto biprocessore con Linux/Windows dovrebbe garantirti utilizzi di
cpu e di disco risibili
E con il fs potresti anche effettuare politiche superiori di caching,
oltre a non aver di mezzo SQL! (che non č poco)
Un database relazionale serve, appunto, quando ci sono relazioni fra i
dati molto forti e molto libere, ossia non note a priori e gestibili ad
hoc dall'utente.
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it