(s-) protezione del software
Moderatore: Moderatori
-
book
- Messaggi: 703
- Iscritto il: lunedì 5 gennaio 2004, 1:00
Premetto che su questo argomento non ho intenzione di fare polemica con stregatto.
Ovviamente Giulio è libero di fare le scelte che ritiene più opportune così come tutti gli altri utenti del forum.
Pertanto, quanto sto per scrivere rispecchia solo il “mio” modo di concepire lo sviluppo in ambiente FM.
Io parto dal fatto che FM è un database di tipo RAD
Punto di forza di questi tipi di database è la velocità!
La velocità di sviluppo, la velocità di aggiornamento, la velocità del “problem solving”…
… in parole povere la possibilità di soddisfare le esigenze del cliente (che è colui che paga) quasi in tempo reale.
Visto da questo punto di vista non ci sono database migliori di FM.
A mio parere, ma ripeto è solo un mio parere, FM deve essere preferito nei casi in cui è prevedibile un continuo e/o immediato aggiornamento del programma.
Al di fuori di questi casi FM “tentenna” al cospetto di altri database.
Appare ovvio che lo sviluppo e lo sviluppatore di FM devono essere del tipo “veloce, scattante”.
Con FM7/8 le cose cambiano…(terza dimensione di FM - leggete altro post)
…adesso un database di FM, anche complesso, può essere “compresso” tutto in un unico file.
...e secondo me questo deve essere fatto!
- In fase di sviluppo:
Io sono del parere, ma è solo il mio parere, che sviluppare su 1 file sia più veloce e conveniente che sviluppare su 3 o 15 file.
Basti pensare a tutti gli script risparmiati.
- In fase di aggiornamento:
Il confronto non regge, aggiornare 1 file è notevolmente più veloce che aggiornare 3 o 15 file.
Questo appare ovvio a tutti…
… anche se molti non si rendono conto delle proporzioni!!!
saluti
p.s. quando ho un attimo di tempo vi descrivo di seguito la separazione logica/dati.
Ovviamente è indirizzata a chi non la sa fare.
Tenetevi pronti!
Ovviamente Giulio è libero di fare le scelte che ritiene più opportune così come tutti gli altri utenti del forum.
Pertanto, quanto sto per scrivere rispecchia solo il “mio” modo di concepire lo sviluppo in ambiente FM.
Io parto dal fatto che FM è un database di tipo RAD
Punto di forza di questi tipi di database è la velocità!
La velocità di sviluppo, la velocità di aggiornamento, la velocità del “problem solving”…
… in parole povere la possibilità di soddisfare le esigenze del cliente (che è colui che paga) quasi in tempo reale.
Visto da questo punto di vista non ci sono database migliori di FM.
A mio parere, ma ripeto è solo un mio parere, FM deve essere preferito nei casi in cui è prevedibile un continuo e/o immediato aggiornamento del programma.
Al di fuori di questi casi FM “tentenna” al cospetto di altri database.
Appare ovvio che lo sviluppo e lo sviluppatore di FM devono essere del tipo “veloce, scattante”.
…effettivamente con FM6 si doveva avere un file master per le relazioni 1/1 + un file per ogni relazione 1/Tanti. Questo era dovuto al fatto che i file FM6 potevano contenere solo 1 tabella.ovviamente sto MOOLTO generalizzando: ogni caso ha la sua soluzione...
Con FM7/8 le cose cambiano…(terza dimensione di FM - leggete altro post)
…adesso un database di FM, anche complesso, può essere “compresso” tutto in un unico file.
...e secondo me questo deve essere fatto!
- In fase di sviluppo:
Io sono del parere, ma è solo il mio parere, che sviluppare su 1 file sia più veloce e conveniente che sviluppare su 3 o 15 file.
Basti pensare a tutti gli script risparmiati.
- In fase di aggiornamento:
Il confronto non regge, aggiornare 1 file è notevolmente più veloce che aggiornare 3 o 15 file.
Questo appare ovvio a tutti…
… anche se molti non si rendono conto delle proporzioni!!!
saluti
p.s. quando ho un attimo di tempo vi descrivo di seguito la separazione logica/dati.
Ovviamente è indirizzata a chi non la sa fare.
Tenetevi pronti!
-
stregatto
- Messaggi: 9700
- Iscritto il: lunedì 1 dicembre 2003, 1:00
- Località: Roma
- Contatta:
mi pare si stia discutendo... la parola "polemica" non era neanche stata pensata, dato che più opinioni ci sono (quando motivate e - possibilmente - competenti), meglio è.Premetto che su questo argomento non ho intenzione di fare polemica con stregatto.
sono d'accordo con il 95% di quanto scrivi. infatti le mie soluzioni di solito hanno un massimo di tre file: soluzione, mailing e aiuto. dico semplicemente che - anche se in linea di massima la cosa migliore è avere un solo file - in alcuni casi è più pratico avere più di un file. Ad esempio per gestire dei "moduli" opzionali, come il client di posta elettronica.
Parlando di "aggiornamenti" intendevo a livello di struttura/scripting, e non di dati, nel qual caso sono ovviamente d'accordo con te.[/quote]- In fase di aggiornamento:
Il confronto non regge, aggiornare 1 file è notevolmente più veloce che aggiornare 3 o 15 file.
-
book
- Messaggi: 703
- Iscritto il: lunedì 5 gennaio 2004, 1:00
Fornitevi di FM 7 o 8 (è solo per ricordarlo, non ho intenzione di descrivere la separazione logica/dati di FM6)
Create un file di nome LOGICA.
Rinominate la tabella LOGICA in “interfaccia”.
Non definite campi
Create un file di nome BASEDATI.
Rinominate la tabella BASEDATI in “dati”.
Nella tabella “dati” create alcuni campi dei vari tipi + 1 solo campo calcolato la cui formula è “2”.
Inserite dei valori a caso nei campi e create qualche record.
Andate nel file LOGICA
- Nel menù file: definisci riferimenti file.
- Nuovo e poi date il percorso del file BASEDATI
Andate nel grafico delle relazioni del file LOGICA
-cliccate su nuova tabella/relazione ed inserite nel grafico la tabella di “dati” del file BASEDATI.
- non effettuate relazioni!!!
Andate nel formato scheda del file LOGICA
- Nuovo formato/resoconto chiamato “1formato”
- Che mostra i record di “dati”.
- inserite i campi che vi interessano selezionandoli tra quelli creati.
Finito!
Il formato chiamato “1formato” (appartenente al File LOGICA) gestisce “TOTALMENTE” i record ed i dati della tabella “dati” (appartenente al file BASEDATI)
Se avete notato non esistono relazioni tra i due file!!!
Per il momento è sufficiente. (i campi calcolo verranno descritti in futuro)
Esercitatevi "a volare" con più tabelle del file BASEDATI e più formati del file LOGICA.
Saluti e Buon divertimento.
p.s. dovete sviluppare (formati, grafica etc.etc.) esclusivamente sui formati del file LOGICA ma con la mente dovete ragionare come se sviluppate sul file BASEDATI…e precisamente (nel caso descritto) sulla tabella “dati”.
Create un file di nome LOGICA.
Rinominate la tabella LOGICA in “interfaccia”.
Non definite campi
Create un file di nome BASEDATI.
Rinominate la tabella BASEDATI in “dati”.
Nella tabella “dati” create alcuni campi dei vari tipi + 1 solo campo calcolato la cui formula è “2”.
Inserite dei valori a caso nei campi e create qualche record.
Andate nel file LOGICA
- Nel menù file: definisci riferimenti file.
- Nuovo e poi date il percorso del file BASEDATI
Andate nel grafico delle relazioni del file LOGICA
-cliccate su nuova tabella/relazione ed inserite nel grafico la tabella di “dati” del file BASEDATI.
- non effettuate relazioni!!!
Andate nel formato scheda del file LOGICA
- Nuovo formato/resoconto chiamato “1formato”
- Che mostra i record di “dati”.
- inserite i campi che vi interessano selezionandoli tra quelli creati.
Finito!
Il formato chiamato “1formato” (appartenente al File LOGICA) gestisce “TOTALMENTE” i record ed i dati della tabella “dati” (appartenente al file BASEDATI)
Se avete notato non esistono relazioni tra i due file!!!
Per il momento è sufficiente. (i campi calcolo verranno descritti in futuro)
Esercitatevi "a volare" con più tabelle del file BASEDATI e più formati del file LOGICA.
Saluti e Buon divertimento.
p.s. dovete sviluppare (formati, grafica etc.etc.) esclusivamente sui formati del file LOGICA ma con la mente dovete ragionare come se sviluppate sul file BASEDATI…e precisamente (nel caso descritto) sulla tabella “dati”.
-
book
- Messaggi: 703
- Iscritto il: lunedì 5 gennaio 2004, 1:00
per Giulio,
Per chiarire le idee e possibilmente usare un linguaggio comune e condiviso.
Lo sviluppo è quando si programma senza ancora aver venduto il software.
L’aggiornamento è quando si aggiorna il software che già contiene i dati del cliente.
Anche se adotti il metodo della separazione logica/dati devi sempre sommare X tempo per aggiornare la struttura/scripting + 0 tempo per aggiornare/importare i dati.
Alla luce dell’impossibilità dello scorporo dei tempi appare evidente che aggiornare 1 file è più veloce che aggiornare 3 file.
Perché il vantaggio (aggiungo minimo in quanto potresti partire da un file base che contenga mailing e help) “di avere un file "tipo" da spostare nelle varie soluzioni senza riscriverlo ogni volta ex-novo” lo hai solo in fase di “scrittura” ovvero di primo impianto e non in fase di “aggiornamento”.
In fase di "aggiornamento" la soluzione migliore è quella di avere a monte la separazione logica/dati che ti azzera il tempo di aggiornare/importare i dati!!!
Tale separazione verrebbe (non poco) incasinata partendo da 3 file piuttosto che di 1. (nota che nella separazione logica/dati i file si raddoppiano)
E l’eventuale vantaggio “di avere un file "tipo" da spostare nelle varie soluzioni senza riscriverlo ogni volta ex-novo” si tramuterebbe in uno "svantaggio".
saluti
Riccardo
p.s. a che punto siete con l'esercitazione.
Per chiarire le idee e possibilmente usare un linguaggio comune e condiviso.
Lo sviluppo è quando si programma senza ancora aver venduto il software.
L’aggiornamento è quando si aggiorna il software che già contiene i dati del cliente.
Parlando di “aggiornamenti” non si può scorporare il tempo che ci vuole per aggiornare la struttura/scripting dal tempo che ci vuole per aggiornare/importare i dati.Parlando di "aggiornamenti" intendevo a livello di struttura/scripting, e non di dati, nel qual caso sono ovviamente d'accordo con te.
Anche se adotti il metodo della separazione logica/dati devi sempre sommare X tempo per aggiornare la struttura/scripting + 0 tempo per aggiornare/importare i dati.
Alla luce dell’impossibilità dello scorporo dei tempi appare evidente che aggiornare 1 file è più veloce che aggiornare 3 file.
Perché il vantaggio (aggiungo minimo in quanto potresti partire da un file base che contenga mailing e help) “di avere un file "tipo" da spostare nelle varie soluzioni senza riscriverlo ogni volta ex-novo” lo hai solo in fase di “scrittura” ovvero di primo impianto e non in fase di “aggiornamento”.
In fase di "aggiornamento" la soluzione migliore è quella di avere a monte la separazione logica/dati che ti azzera il tempo di aggiornare/importare i dati!!!
Tale separazione verrebbe (non poco) incasinata partendo da 3 file piuttosto che di 1. (nota che nella separazione logica/dati i file si raddoppiano)
E l’eventuale vantaggio “di avere un file "tipo" da spostare nelle varie soluzioni senza riscriverlo ogni volta ex-novo” si tramuterebbe in uno "svantaggio".
saluti
Riccardo
p.s. a che punto siete con l'esercitazione.
-
book
- Messaggi: 703
- Iscritto il: lunedì 5 gennaio 2004, 1:00
Aggiornando questo file da casa e postandolo al cliente aggiornerete il programma senza effettuare l'importazione dei dati.
il cliente dovrà limitarsi a sostituire il file LOGICA.
(attenzione ai riferimenti ai file: ottimizzate ed uniformate a monte l'installazione presso i clienti)
Dovete mantenere lo stesso nome e per le runtime anche la stessa chiave di vincolo.
saluti e buon lavoro
Riccardo
il cliente dovrà limitarsi a sostituire il file LOGICA.
(attenzione ai riferimenti ai file: ottimizzate ed uniformate a monte l'installazione presso i clienti)
Dovete mantenere lo stesso nome e per le runtime anche la stessa chiave di vincolo.
saluti e buon lavoro
Riccardo
Ultima modifica di book il sabato 5 aprile 2008, 15:18, modificato 2 volte in totale.
-
Pirata
- Messaggi: 1197
- Iscritto il: domenica 12 marzo 2006, 1:00
- Versione FileMaker: 18
- Sistema operativo: Win10
- Località: Reggio Calabria (RC)
Riccardo, devo dire meraviglioso.
Ho provato anch'io ed è veramente simpatico il fatto di interagire con un altro file magari, senza relazione!
Ma è risolto veramente così il problema aggiornamento?
Sì => se non dovrò più toccare il database centrale (ossia aggiungere campi o variare un campo testo in calcolato...);
No => caso opposto.
Non voglio smontare il tuo operato, ma essendo un problema molto serio, vorrei vederlo e ragionarlo insieme a voi a 360°.
Ho provato anch'io ed è veramente simpatico il fatto di interagire con un altro file magari, senza relazione!
Ma è risolto veramente così il problema aggiornamento?
Sì => se non dovrò più toccare il database centrale (ossia aggiungere campi o variare un campo testo in calcolato...);
No => caso opposto.
Non voglio smontare il tuo operato, ma essendo un problema molto serio, vorrei vederlo e ragionarlo insieme a voi a 360°.
-
book
- Messaggi: 703
- Iscritto il: lunedì 5 gennaio 2004, 1:00
L’aggiornamento è risolto.
Tanti sviluppatori utilizzano il metodo della separazione dei dati dalla logica.
La maggior parte risiede all’estero e lavora sui mac.
In Italia il metodo è poco conosciuto e poco adottato (purtroppo).
1) domanda: Aggiungere campi in BASEDATI
2) domanda: variare un campo testo in calcolato.
totalmente illogico (se ti necessita fare questo vuol dire che non hai effettuato una corretta analisi di progettazione del DB)
Tu conosci il mio indirizzo E-mail, se mi invii il tuo, ti posto un sintetico esempio in FM.
Il resto lo devi mettere tu.
saluti
Riccardo
Tanti sviluppatori utilizzano il metodo della separazione dei dati dalla logica.
La maggior parte risiede all’estero e lavora sui mac.
In Italia il metodo è poco conosciuto e poco adottato (purtroppo).
1) domanda: Aggiungere campi in BASEDATI
aggiungo: in ogni tabella del file BASEDATI (un bravo sviluppatore di FM 7/8 riesce a ridurre di molto il numero di tabelle)****create nel file BASEDATI qualche campo in più nei vari tipi da lasciare vuoto per un eventuale utilizzo negli aggiornamenti.
2) domanda: variare un campo testo in calcolato.
totalmente illogico (se ti necessita fare questo vuol dire che non hai effettuato una corretta analisi di progettazione del DB)
Tu conosci il mio indirizzo E-mail, se mi invii il tuo, ti posto un sintetico esempio in FM.
Il resto lo devi mettere tu.
saluti
Riccardo