TTreeView

[Avogadro]

TTreeView è , mi si passi il termine, un "contenitore" di informazioni che si poggia sulla ben nota tecnica degli alberi binari.

Torna utile in tante applicazioni,  in particoalre lo sto usando per "clonare" i record di tabelle sqllite  legate tra di loro da piu' relazioni master-detail.

Purtuttavia sto avendo difficoltà a trovare informazioni su di esso, dove le potrei reperire ?

Inoltre sto usando ZeosLib e Fortes Reprt, ma anche in questo caso reperire informazioni per usarli al meglio è dura, google et similia non forniscono granchè in merito; qualcuno sa dove reperire informazioni in merito ?
 
Grazie anticipate.

 



 

[bonmario]

Ciao,
sotto la directory di installazione di Lazarus ci sono degli esempi:
C:\Lazarus\examples\treeview

In rete, io all'epoca ero partito da qui:
http://wiki.freepascal.org/TTreeView
http://wiki.lazarus.freepascal.org/XML_Tutorial#Populating_a_TreeView_with_XML

Ciao, Mario

[Avogadro]

Grazie 

Con l'occasione vorrei discutere un'idea.

Da premettere che qualcosa di simile mi pare già di averla vista dalle parte degli applicativi di delphi.

Allora, ai fini della rintracciabilià di tutte le operazioni compiute nell'ambito di un laboratorio di analisi,   ho creato una serie di tabelle (15 )   legate tra di loro in una serie di relazioni uno a molti (o master detail che dir si voglia) .

Applicando le consuete regole di normalizzazione la banca dati va.

Purtuttavia, ai fini di semplificare la vita agli utenti, sto cercando di creare una interfaccia intuitiva  in cui il "cut& paste" dei  record di tabelle tra di loro collegate sia un'operazione affidabile e semplice allo stesso tempo (c'è un "template"  di record da complilare ogni volta)  e in questo il treeviev è stato di grande aiuto.

Osservano pero' il treeview popolato con  i dati delle tabelle sembra possibile questa operazione: e se il treeview si potesse scaricare in campo testo, ad esempio di sqllite, magari come una struttura xml o meglio json ?

Cioè che richiede 15 tabelle master detail potrebbe essere "compresso" in struttura ad albero poi a sua volta compressa in semplice campo testo.

Ovviamente si perderebebro  i vantaggi delle query, ma smanettando un attimo con gli alberi binari e altre cosette carine già presenti in lazarus (es. tstring list - http://www.delphibasics.co.uk/RTL.asp?Name=tstringlist)  la creazione di form, statistiche e report non dovrebbe essere difficile, anzi, dovrebbe essere semplificata per via dell'approccio piu' intuitivo del treeviev (magari addobbato con po' di icone colorate).

Che ne pensate ?  E' fattibile una banca dati non poggiata su tabelle tra di loro collegate ma su alberi binari  ?


 

[nomorelogic]

ciao
quello che dici non è impossibile, anzi, il json si presta benissimo a rappresentare questi tipo di dati.

Il problema potresti averlo più tardi, quando ad esempio fra un po' di tempo potresti trovarti ad aggiungere qualche campo su qualche tabella e/o nuove tabelle, introdurre nuove relazioni e così via.

Se hai già individuato la struttura del database e sai che oramai è difficile che cambi, puoi anche farlo.
Se non sei sicuro di aver terminato i lavori (compresi tutti i tipi di report e statistiche) io rimarrei con i dati in un RDBMS.

[Stilgar]

Ciao.
Se ho capito bene vorresti mettere in piedi una sorta di back end no sql.se definisci correttamente gli oggetti basse che permettano di essere estesi con strumenti esterni al codice del programma, magari eviti problemi in futuro.
Poi puoi fare la persistenza del dato dentro un database relazionale, xml, json o file binari in un tuo formato.
Diciamo che la questione non è proprio banale.
Suggerirei un disaccoppiamento tra il dato usato e quello salvato.
Il programma , nel tuo caso andrebbe a nozze col pattern proxy classes .
In pratica usando 3 strutture al posto di una sola diretta.
Definisci l'interfaccia che è ti descrive i dati. Ipotesi il classico utente. Nome cognome e altri dati.
Una classe concreta che mantiene le informazioni.
La classe proxy che carica la classe completa solo se vengono accadute le proprietà di quest'ultima.
Il vantaggio lo trovi nelle collezioni di molto oggetti e di oggetti grossi in memoria. Potrebbe essere il tuo caso (da quel che capisco).
Se una riga è collegata ad un'altra la seconda sarà caricata solo se viene espanso l'albero, in modo puntuale e non  avrai memoria occupata per le righe non visibili.

Se implementa correttamente la soluzione con le proxy classes può dare ottimi risultati.

Penso ad hibernate per java o doctrine per php quando cerco astrazioni sui relazionali. Usano meccanismi
 Proxy.

Sappi che all'inizio sarà lunghetto imbastire la soluzione a manina.

Stilgar

[Avogadro]

Grazie per i suggerimenti.

 

In effetti c'è sempre il probema di  base di poter aggiungere o cambiare dei campi o i report in un qualunque momento, in base alle nuove esigenze che man mano sopravvengono;  generalmente un data base relazionale classico, con la sua brava standardizzazione ansi sql,  ben si presta a cio' .

 Pututtavia l' idea di potersi sganciare da un data base classico, che pretende sempre un software di amministrazione ad hoc - non sempre facilmente gestibile e sopratutto reperibile - ,  e il poter e gestire tutto con dei semplici file di testo e un po' di classica programmazione mi intriga .

L' idea del pattern proxy classes mi intriga e vorrei approfondire , un suggerimento dove poter attingere un po' di informazioni in piu' ?


Grazie ancora ed auguri a tutti.

 

[SB]

La cosa è fattibile e personalmente la uso. Non ci sono particolari problemi per le modifiche se fai il codice in maniera intelligente.
Però mi vengono in mente alcuni problemi, visto che parli di "utenti".
1. c'è accesso multiutente ai dati?
2. quanto deve essere affidabile il salvataggio?
3. che massa di dati hai?
4. dove risiedono i dati?
ecc.
In sostanza i problemi per cui di solito si sceglie un database server...

[Stilgar]

Avogadro. Inizia con Google e trova articoli che ti spieghino le cose.
Oppure parti da Wikipedia.
Come ti trovi meglio.
Stilgar

[Avogadro]

La cosa è fattibile e personalmente la uso. Non ci sono particolari problemi per le modifiche se fai il codice in maniera intelligente.
Però mi vengono in mente alcuni problemi, visto che parli di "utenti".
1. c'è accesso multiutente ai dati?
2. quanto deve essere affidabile il salvataggio?
3. che massa di dati hai?
4. dove risiedono i dati?
ecc.
In sostanza i problemi per cui di solito si sceglie un database server...

Appunto , ecco perché finora mi son sempre poggiato sui classici data base relazionali (per adesso uso sqllite).

La mia voleva essere una prima esplorazione di un nuovo approccio  (almeno per me )  al  mondo delle banche dati e mi conforta sapere che la mia idea è una strada già esplorata.

Tornado alle domande:
" 1. c'è accesso multiutente ai dati?"

Si, per adesso gli utenti sono pochi (meno di 10) , ma il loro numero dovrebbe man mano aumentare  , quidi si che c'è il problema della multiutenza.

"2. quanto deve essere affidabile il salvataggio?"

Deve essere piu' che affidabile sia perché nell' ambito in cui lavoro le norme di qualità dei prodotti e dei servizi prevedono la rintracciablità completa dei dati degli ultimi 10 anni (mica uno scherzo, visto che in 10 anni la tecnologia galoppa ma purtutatvia il classico cd di backup non funziona piu' dopo due mesi  o magari l'operatore dell' l'hosting remoto ha chiuso i battenti o, ancora, il cliente non vuole che i suo dati siano chissà dove sul pianeta) , sia perché non puo' assolutamenet accadere che dopo il data entry i dati  vadano persi  per una qualsiasi ragione.

"3. che massa di dati hai?"
Il problema non è solo la massa di dati, che è elevata ,  il problema principale sono le dipendenze tra i dati; il problema  è sorto quando ho applicato le classiche regole di normalizzazione delle banche dati alla mia sitauzione: il numero di tabelle da gestire è attualmente pari a 15,  tutte correlate tra di loro con relazioni uno a molti in cascata ; a queste se ne aggiungeranno altre  che avranno le relazioni del tipo molti a molti (situazione che vorrei evitare perché fonte di problemi da parte di utenti poco ferrati).
Uno dei problemi  è proprio qui: nel complesso delle relazioni che poi si ripercute sull' interfaccia con l' utenza che diventa macchinosa (clonare dei record e i relativi sottorecord , ad esempio, non è banale con 15 tabelle collegate tra di loro- ne' si riesce a diminuire il loro numero senza perdere la normalizzazione dei dati ) ;
Ecc operché vorrei creare un'interfaccia robusta che prevenga data entry errati e che sia nel contempo agevole e non machinosa. Nel mio caso questo non è banale perché i dati sono complessi, le situazioni sempre diverse, il materiale umano disponibile non è il top e con quello bisogna arrangiarsi,  e pertanto ci vuole una forte astrazione  per concepire un modello concettuale che regga.
Proprio per questo avevo pensato ad un approccio ad alberi binari  viusalizzati attarverso il treview, perchè è piu' intuitivo di una serie di tabelle in cascata  che magari si espandono su piu' form .
 
Giusto per chiarire  l' ambito in cui opero: esso è il controllo di qualità delle merci , controlli che devono seguire tutta una serie di regole molto severe,  tra le quali vi è  lo standard  Title 21 cfr ( https://en.wikipedia.org/wiki/Title_21_CFR_Part_11 )  .

Si c'è gia del software commerciale  disponibile, ma le esperienze finora sono non sono state per nulla soddifacenti, anzi sono state un disastro con operatori esasperati dalla loro macchinosità  in quanto tutte le classiche regole di normalizzazione dei dati,  di sicurezza delle transazioni ,  di interfacce che non esauriscano  gli operatori  etc , pare che poi nella realtà non vengano mai applicate .

Quindi vi è il tentativo aziendale di farsi un software ad hoc piuttosto che svenarsi con la ricerca continua del vestito che stia addosso in maniera non dico perfetta ma almeno acettabile .

"4. dove risiedono i dati?"

Ovviamente su un server in remoto,  e quindi c' il problema della sicurezza delle transazioni.


In sintesi:  diceva la pubblicità di  Delphi : "trasformate il caos dei vostri clienti in risorsa",  speriamo di risuscirci.

 
Ciao e grazie

[Avogadro]

Avogadro. Inizia con Google e trova articoli che ti spieghino le cose.
Oppure parti da Wikipedia.
Come ti trovi meglio.
Stilgar

Allora, ho già fatto le ricerche con google, ci mancherebbe altro che non le avessi già fatto; il punto è risucire a trovare le dritte giuste senza annegare nel mare delle migliaia di infomazioni che un motore di ricerca restituisce, per questo avevo chiesto se erano noti dei siti, dei pdf o quant'altro già "collaudati" su questi argomenti.

Il problema di google et silimilia è l' overflow di informazioni: l'eccesso di informazioni paradossalmente puo' rendere poco efficace le decisioni o gli studi su un dato argomento (diceva il filosofo «È inutile fare con più ciò che si può fare con meno» ).

Non solo, ma a qualcuno è venuta l' infelice idea di reificare il pregiudizio di conferma nel codice dei motori di ricerca  i quali studiano l' utente e gli restituiscono sempre le risposte a lui gradite, risposte basate sulle esplorazioni passate e che hanno come effetto di rinchiudere di fatto l' utente in una bolla di pregiudizi e luoghi comuni dalla quale poi non riesce piu' ad uscire (con buona pace del progresso e dell'esplorazione di nuovi orizzonti).

Saludos.

[SB]

La cosa è fattibile e personalmente la uso. Non ci sono particolari problemi per le modifiche se fai il codice in maniera intelligente.
Però mi vengono in mente alcuni problemi, visto che parli di "utenti".
1. c'è accesso multiutente ai dati?
2. quanto deve essere affidabile il salvataggio?
3. che massa di dati hai?
4. dove risiedono i dati?
ecc.
In sostanza i problemi per cui di solito si sceglie un database server...

Appunto , ecco perché finora mi son sempre poggiato sui classici data base relazionali (per adesso uso sqllite).

La mia voleva essere una prima esplorazione di un nuovo approccio  (almeno per me )  al  mondo delle banche dati e mi conforta sapere che la mia idea è una strada già esplorata.

Tornado alle domande:
" 1. c'è accesso multiutente ai dati?"

Si, per adesso gli utenti sono pochi (meno di 10) , ma il loro numero dovrebbe man mano aumentare  , quidi si che c'è il problema della multiutenza.

"2. quanto deve essere affidabile il salvataggio?"

Deve essere piu' che affidabile sia perché nell' ambito in cui lavoro le norme di qualità dei prodotti e dei servizi prevedono la rintracciablità completa dei dati degli ultimi 10 anni (mica uno scherzo, visto che in 10 anni la tecnologia galoppa ma purtutatvia il classico cd di backup non funziona piu' dopo due mesi  o magari l'operatore dell' l'hosting remoto ha chiuso i battenti o, ancora, il cliente non vuole che i suo dati siano chissà dove sul pianeta) , sia perché non puo' assolutamenet accadere che dopo il data entry i dati  vadano persi  per una qualsiasi ragione.

"3. che massa di dati hai?"
Il problema non è solo la massa di dati, che è elevata ,  il problema principale sono le dipendenze tra i dati; il problema  è sorto quando ho applicato le classiche regole di normalizzazione delle banche dati alla mia sitauzione: il numero di tabelle da gestire è attualmente pari a 15,  tutte correlate tra di loro con relazioni uno a molti in cascata ; a queste se ne aggiungeranno altre  che avranno le relazioni del tipo molti a molti (situazione che vorrei evitare perché fonte di problemi da parte di utenti poco ferrati).
Uno dei problemi  è proprio qui: nel complesso delle relazioni che poi si ripercute sull' interfaccia con l' utenza che diventa macchinosa (clonare dei record e i relativi sottorecord , ad esempio, non è banale con 15 tabelle collegate tra di loro- ne' si riesce a diminuire il loro numero senza perdere la normalizzazione dei dati ) ;
Ecc operché vorrei creare un'interfaccia robusta che prevenga data entry errati e che sia nel contempo agevole e non machinosa. Nel mio caso questo non è banale perché i dati sono complessi, le situazioni sempre diverse, il materiale umano disponibile non è il top e con quello bisogna arrangiarsi,  e pertanto ci vuole una forte astrazione  per concepire un modello concettuale che regga.
Proprio per questo avevo pensato ad un approccio ad alberi binari  viusalizzati attarverso il treview, perchè è piu' intuitivo di una serie di tabelle in cascata  che magari si espandono su piu' form .
 
Giusto per chiarire  l' ambito in cui opero: esso è il controllo di qualità delle merci , controlli che devono seguire tutta una serie di regole molto severe,  tra le quali vi è  lo standard  Title 21 cfr ( https://en.wikipedia.org/wiki/Title_21_CFR_Part_11 )  .

Si c'è gia del software commerciale  disponibile, ma le esperienze finora sono non sono state per nulla soddifacenti, anzi sono state un disastro con operatori esasperati dalla loro macchinosità  in quanto tutte le classiche regole di normalizzazione dei dati,  di sicurezza delle transazioni ,  di interfacce che non esauriscano  gli operatori  etc , pare che poi nella realtà non vengano mai applicate .

Quindi vi è il tentativo aziendale di farsi un software ad hoc piuttosto che svenarsi con la ricerca continua del vestito che stia addosso in maniera non dico perfetta ma almeno acettabile .

"4. dove risiedono i dati?"

Ovviamente su un server in remoto,  e quindi c' il problema della sicurezza delle transazioni.


In sintesi:  diceva la pubblicità di  Delphi : "trasformate il caos dei vostri clienti in risorsa",  speriamo di risuscirci.

 
Ciao e grazie

Per quel che hai scritto la soluzione apparentemente migliore rimane il database relazionale. SQLServer mi pare sia gratuito fino a un certo tot di dati che di solito è sufficiente. SQLLite non lo conosco quindi non mi esprimo.
Non meravigliarti per il numero di tabelle. Per una applicazione fatta bene e di una certa complessità è normale averne decine.
Ti consiglio di fare una buona analisi e di dare al database la struttura che necessita per quanto complessa sia. Ignora le "esigenze" dell'utente. Per l'accesso degli utenti esistono altri strumenti che semplificano la vista dei dati.

Altre forme di archivio dati per il tuo caso a mio parere non sono utilizzabili.
L'accesso multiutente ti obbliga a meccanismi di lock dei dati, e nel tuo caso potrebbe essere l'intero database.
L'affidabilità del salvataggio ti obbliga ad implementare meccanismi di backup temporaneo e controllo della correttezza del salvataggio (transazioni).
La massa di dati ti obbliga al trasferimento in rete, con problemi di tempo e sicurezza.

Spesso usare un software commerciale può risultare stretto, ma tieni presente che esso (se fatto seriamente) è frutto di una analisi da parte di gente esperta (si spera), che per quanto tu sia esperto probabilmente ha più esperienza di te perchè fa quello per lavoro.
Per quello che è la mia esperienza spesso sono le aziende ad operare in maniera "illogica" (gli operatori che fanno a modo loro perchè si fa così...) e si lamentano che poi è il software ad essere fatto male.
La tentazione di farsi il software in casa è forte, ma si sottovalutano nettamente i costi complessivi e le problematiche da affrontare.
Che tu sia interno all'azienda o un programmatore esterno, secondo me faresti meglio a lasciare il software esistente e creare piuttosto delle interfacce di accesso ai dati.
Lavoro ne avresti comunque ed eviteresti di infognarti.

[nomorelogic]

Un database relazionale è quello che ti serve, una tree-view è solo un controllo per visualizzare dei dati.

sqlite gestisce la multiutenza ma bloccando tutto il database nel momento della scrittura; già 10 utenti sono troppi per una situazione del genere.

ci sono molte soluzioni: ms sql express, postgressql, firebird

firebird è un ottimo compromesso tra prestazioni e facilità di manutenzione (che prossima allo zero: installi e te lo dimentichi)

[xinyiman]

Suggerisco anche io firebird, di gran lunga il miglior database relazionale al mondo per rapporto qualità/prezzo/semplicità

[SB]

MS SQLServer è considerato uno dei migliori RDBMS ed è gratuito fino 10GB di dati (che sono tanti). E' un po' difficile scartarlo a priori se si sta pensando ad un programma commerciale, se non altro per il marchio.
A meno che non si voglia qualcosa di multipiattaforma e allora si potrebbe valutare MySQL o PostgreSQL
Non so se Oracle offra gratuitamente una versione ridotta.
Personalmente non conosco firebird e per quanto ne so può anche essere il miglior db del mondo, ma per un componente chiave di una applicazione sarei cauto nell'orientarmi su qualcosa open source con alle spalle una fondazione che non mi dà alcuna garanzia...
Può suonare una bestialità in un forum dedicato ad un ambiente di sviluppo open source, ma se sballa un programma me ne accorgo e lo sistemo, se un database mi perde dati... possono essere guai grossi per l'azienda e per il programmatore.

[nomorelogic]

Personalmente non conosco firebird e per quanto ne so può anche essere il miglior db del mondo, ma per un componente chiave di una applicazione sarei cauto nell'orientarmi su qualcosa open source con alle spalle una fondazione che non mi dà alcuna garanzia...

uso firebird da quando fece il fork da Borland Interbase, non voglio fare i conti per non ricordarmi quanti anni ho
spesso un programma open source non da garanzia, ma firebird fa parte di quei programmi open source che hanno attraversato lustri (ricordo che siamo nel settore informatico) e sono stati sempre presenti ed efficienti (ho delle installazioni software con ancora la versione 2.0, tra 1 e 8 GB di database e non fanno una piega)