Splittare o non splittare il DB

[Zago_87]

Ho creato un DB per un amico ormai anni fa e ho questi problemi/necessità:
1) PERDITA DI DATI

• - Lui litiga con i pc, riesce spesso a inchiodare tutto (non capisco come)
  - il DB sta diventando sempre più pesante ed è diventato un po' più lento nel caricamento di alcune ricerche o alcuni rapporti e questo non lo aiuta ad evitare danni (il classico vizio di cliccare ripetutamente sui pulsanti e ovunque quando le cose non si aprono in un millisecondo)
  - Lo utilizza principalmente su un Intel NUC a bordo del suo furgone, a volte la batteria ausiliaria dedicata cala di voltaggio e il PC si spegne di brutto

In questi casi non sempre riesce a recuperare il file .odb con conseguente perdita di dati. Per fortuna si ricorda di fare backup manuali abbastanza spesso e il problema è contenuto (a breve conto di automatizzare il backup).

2) LENTEZZA

• Come già accennato i dati cominciano ad essere tanti e il DB appesantito, lento.

3) TRASFORMAZIONE IN MULTIUTENTE

• Ormai da tanto mi chiede di rendere il DB multiutente, in questo caso splittare mi permetterebbe di mettere i dati su un server distribuendo copie solo del front end.

4) AGGIORNAMENTO DELLE FUNZIONI RAPIDO

• Vorrei semplificare il rilascio di nuove versioni, ora sono costretto a lavorare su una copia, poi andare da lui e copiare e incollare i dati delle varie tabelle nella mia nuova versione.

5) PROTEZIONE DELLA STRUTTURA DEL DB

• A volte è anche capitato che vada a mettere mano dove non deve danneggiando proprio la struttura del DB visto che se nascondo la finestra principale di BASE ho problemi chiudendo le anteprima di stampa (viewtopic.php?f=13&t=7347), quando le chiudo si chiude tutto il DB.

Ho cercato nel forum e sembra che splittare il database aiuti ad evitare la perdita dei dati (1), ad esempio in caso di spegnimenti improvvisi, ma aiuti anche quando i dati diventano tanti, velocizzando un po' il DB (2) e dovrebbe anche essere l'unica strada per il multiutente (3). Non so se possa aiutarmi nel rilasciare nuove versioni più facilmente (4) (il file con le tabelle dati è un file a parte?) o possa semplificarmi la protezione della struttura del DB (5) ma questo credo di no.

Insomma...visti i problemi e le esigenze di cui sopra, splittare è la strada migliore che posso provare?
Il tutorial di Charlie a riguardo (viewtopic.php?f=13&t=7244) resta il più aggiornato per ottenere ciò che voglio?

[charlie]

Insomma...visti i problemi e le esigenze di cui sopra, splittare è la strada migliore che posso provare?

Non so se sia la strada migliore ma l'alternativa è quella di usare Base con altri motori (Msql ..... altri).

Il tutorial di Charlie a riguardo (viewtopic.php?f=13&t=7244) resta il più aggiornato per ottenere ciò che voglio?

Puoi trovare maggiori dettagli nel forum inglese da cui mi sono ispirato.

[Zago_87]

Non so se sia la strada migliore ma l'alternativa è quella di usare Base con altri motori (Msql ..... altri).

Ho installato il pacchetto MySQL tempo fa perché volevo provare questa strada, dove lavoravo mi avevano dato accesso alla struttura del nostro gestionale perché avevo imparato a scrivere query e usavo Workbench per testarle, quindi speravo di avere già familiarità. Beh ovviamente un conto è questo utilizzo molto limitato, ben altro trasferirci/crearci un nuovo DB, mi sono un po' bloccato. Però se ne vale la pena, se miglioro o risolvo nei punti che ho indicato, cerco di studiarci su ancora. Mi pare che nei "nostri" forum non ci sia un tutorial per il trasferimento del back end su MySQL, o sbaglio?

Puoi trovare maggiori dettagli nel forum inglese da cui mi sono ispirato.

Ho letto diverse cose sul forum inglese ma ammetto di essermi a volte perso perché spesso la discussione virava un po' troppo sul tecnico

Ho creato con la tua procedura un DB splittato, sto cercando di importare tutto dal vecchio e poi farò dei test, spero di poter apprezzare pro e contro dell'operazione abbastanza velocemente

La mia speranza era trovare qualcuno più o meno nella mia situazione che abbia risolto, tipo viewtopic.php?f=13&t=9893&p=59277&hilit=mysql#p59277 ma non abbiamo il finale

[Zago_87]

Nel poco tempo che posso dedicare in questi giorni al progetto intanto posso dire che splittare risolve:
1) PERDITA DATI

• Ho provato a spegnere forzatamente il pc e anche a terminare il processo soffice, sempre saltando il ripristino dati di LO e non ho avuto alcun problema al momento, il DB si è sempre riaperto correttamente con tutti i dati aggiornati

4) AGGIORNAMENTO DELLE FUNZIONI RAPIDO

• 1) Mi copio la cartella che contiene il DB e me la porto a casa (ho simulato creando una copia in altro posizione del pc)
  2) Modifico l'odb cambiando formulari, aggiungendo ricerche, rapporti, ecc.
  3) Sostituisco l'odb nella cartella di chi utilizza il file (mi tengo la copia della versione precedente per sicurezza) ed è subito operativo con i dati aggiornati

Questo se non devo modificare le tabelle o crearne di nuove. Se provo infatti a crearne una nuova e poi spostare il file nella posizione di lavoro, questa scompare alla riapertura del file.
Credo quindi che sia utile splittare il DB quando siamo in una situazione stabile dal punto di vista della struttura dei dati, perché altrimenti ogni modifica diventa più complessa del necessario.

Fin qui ho capito e agito bene oppure mi sono perso qualcosa?

Detto questo ho notato un "problema":
Ho aggiunto varie tabelle dal mio DB originale a quello splittato ottenuto con il tutorial di Charlie, in pratica ad ogni modifica dell'odb si crea un file di testo con le istruzioni per editare il file .data con le nuove modifiche. Alla chiusura del DB questo file viene eseguito e poi sparisce mentre il file .data aumenta di dimensione. Ho notato che se aggiungo ed elimino la stessa tabella n volte, il file .data aumenta soltanto, non diminuisce quando la elimino.

Questo comportamento è corretto? Il file .data tiene traccia di ogni cosa, sia stata modificata in aggiunta ed eliminazione?

[charlie]

Non ho esperienza pratica.
Come te la cavi con l'inglese?

[Zago_87]

Abbastanza bene, anche se linguaggio tecnico di programmazione ho visto mi resta un po' ostico a volte.
Come già detto ho provato a leggere dal forum inglese tutto quello che ho trovato sull'argomento ma mi sono sempre perso...

Mi piacerebbe testare la cosa e lasciare la mia esperienza qui sul forum italiano, il mio DB più grande è abbastanza complesso e vario, potrebbe essere un test valido, ma ho tanto da imparare e al momento sono un po' perso, non so che strada intraprendere.

Se hai qualcosa da linkarmi posso provare a seguirlo, in qualche modo devo far fare una evoluzione al DB prima che diventi davvero un problema.

Grazie

[charlie]

In realtà ti proponevo di cercare assistenza sul forum inglese.

[Zago_87]

Ah ok, certo! Mi iscrivo e provo a cercare supporto con loro, se risolvo positivamente posto qui il risultato.

Al momento ho optato per la soluzione split, non proverò al momento MySQL. Credo di poter dire di aver risolto su un piccolo DB di prova i diversi problemi di cui parlavo, mi restano solo questi due dubbi:

• 1) seguire il tuo tutorial e quindi creare un DB vuoto per poi importare dal vecchio tabelle, Ricerche, Formulari, Rapporti e Macro è equivalente alla procedura ad esempio descritta qui: viewtopic.php?f=6&t=1485 che invece opera direttamente sul DB originale? Ottengo lo stesso identico risultato?
  2) Perché il file .data continua ad espandersi costantemente anche quando in realtà rimuovo dati? Non rischio che diventando enorme avrò problemi prima o poi? Si tratta di un "problema" solo mio oppure è il normale funzionamento?

Editato: Problema risolto!!! Ora non so se sia un lampo di genio, un colpo di calore o una botta di c... sta di fatto che mi è venuto in mente di tentare un checkpoint defrag...ebbene il file .data torna della dimensione corretta!!! Mi applaudo da solo perché mi sono risparmiato un post in inglese Ora il dubbio è, visto che credo dipenda da come è realizzato lo split nel file Split_HSQLDB_2.3.2_Wizard_v3d.odb, è una cosa che andrebbe segnalata a chi gestisce il file? Credo sia sufficiente impostare il defrag in chiusura dell'applicativo o forse in apertura (non so dove sia meglio). Dico bene Charlie?

[charlie]

Probabilmente hai già acquisito esperienza superiore alla mia.
Io mi sono fermato alla prova della funzione DATEADD che mi interessava in quel momento.
Vai in ricerca sul forum inglese, digita "split database" e ti si aprirà tutto un mondo ...

[Zago_87]

Probabilmente hai già acquisito esperienza superiore alla mia.

Vai piano...non credo proprio...le mie lacune si fanno sempre sentire molto forte

Intanto, visto che per ora non sono riuscito a fare di meglio, posto il codice di un pulsante che chiude il formulario (che nel mio caso funge da menù principale) facendo prima il checkpoint defrag così da compattare il database splittato:

Codice: Seleziona tutto

Sub Esci
	If MsgBox("Vuoi veramente uscire dal programma?" & chr(13) & chr(13) &_
		"Proseguendo tutti i dati non salvati andranno persi " & chr(13) & " ", 308, "Attenzione!") = 6 Then
		ThisComponent.CurrentController.Frame.Close (True)				REM Chiude il formulario
		oConn = ThisDatabaseDocument.CurrentController.ActiveConnection
		If Not (oConn Is Nothing) Then
			oStatement = oConn.CreateStatement ()
 			oStatement.Execute ("checkpoint defrag")
 		End If
		ThisDatabaseDocument.Close (True)				REM Chiude il database
		Else
	End If
End Sub

Ora come suggerito mi immergo nel mondo inglese, voglio capire se importare tutto sul DB del tutorial o splittare l'originale, quale sia la soluzione migliore ammesso che una differenza ci sia in termini di risultato finale.

Quando avrò news posto e poi magari scriverò un resoconto.

Intanto grazie