Come funziona filemaker, internamente?

[Vash1986]

Salve, sono uno studente di ingegneria informatica e mi piace lavorare coi database.
Filemaker mi incuriosisce da tempo, lo conobbi grazie ad un software gestionale tempo fa e ci ho giocherellato un po' con delle versioni di prova.

Ho anche letto un libro, Filemaker Bible, abbastanza chiaro e completo. Insomma, so cos'è, so come farci i database e so come usarlo, discretamente.

Tuttavia non riesco a trovare un libro o una documentazione che spiega i meccanismi di funzionamento interno. Voglio dire, bene o male tutti gli informatici sanno come funziona un DBMS classico (interprete query, ottimizzazione, transazioni, lock, roll-back, caching, indexing, ecc). Ma riguardo al filemaker non ho trovato nulla. E purtroppo ho dei sospetti atroci sul suo funzionamento.

Da quel che ho potuto vedere temo che il filemaker server (o il filemaker pro che condivide un file) sostanzialmente condivide sulla rete i file PER INTERO ai vari client che ne richiedono l'utilizzo e poi gestisce la sincronizzazione fra i client, informandoli di eventuali modifiche. E ho anche il sospetto che i client si portino addosso il peso di qualsiasi operazione da compiere sul database, come la ricerca e l'ordinamento.

E' giusta quest'impressione che ho avuto? Esistono libri che spiegano bene come funziona il filemaker da questo punto di vista?

[stregatto]

no, in quanto la FMI non incoraggia l'introspezione…

in linea di massima non hai torto (con qualche distinguo sul caricamento per intero). sbagli invece su una questione fontamentale. in realtà FM NONè un DBMS, ma un ambiente di sviluppo, comprendente al suo interno anche un DB.

.g.

[Vash1986]

No infatti mi son espresso male. Filemaker non è un DBMS, è appunto un gestore di file (chissà che non usi sqlite )
Grazie per la risposta.

[stregatto]

no, non usa SQLLite. In sostanza è scritto in C e C++ con qualche pezzo in perl. fondamentalmente i file sono stringoni di testo e il perl serve per vlocizzare l'estrazione. nel passaggio dalla versione 6 alla 7 si era parlato di un utilizzo di un motore SQL, ma poi non si è proceduto in questa direzione.

.g.

[book]

inoltre il record locking e la sincronizzazione è fatta sul server (o host) e non vengono trasferiti "i file per intero".
In pratica il server ti invia la base di un formato, quello che vedi andando in modo trova, che viene caricata sul client e poi ti invia a richiesta i dati da visualizzare (pochi Byte in effetti...per i campi non contenitore).

Molte operazioni, quali ordinamento, ricerche ed alcuni calcoli sono fatte sul client, mentre il server tiene l'indicizzazione.

[Vash1986]

Capisco. Come RAD filemaker è grandioso, peccato che utilizzi questo bizzarro metodo di condivisione piuttosto che un sistema client-server basato su query.

[stregatto]

È un approccio diverso. appunto, un RAD.

.g.

[book]

...bizzarro metodo di condivisione...

Considera che sul client hai una versione pagata e funzionante di FM, ed utilizzano una parte della potenza di calcolo del client per alleggerire il carico sul server e sulla rete, dov'è la bizzarria?
Io ho server a qualche decina di KM dai client e sembra di averli sotto la scrivania.
Inoltre FM è multipiattaforma e come tale lo scambio dei dati è ad un livello base.
Ogni file, tabella, campo, formato, record, script..etc ha un numero interno.
Il valore "ciao" del campo 36 del record 1234 della tabella 5 del file 11 si riduce a qualcosa di simile:
11,5,36,1234,ciao.
Quindi il server invia la "matrice" del formato al caricamento dello stesso e poi stringhe di testo.
Allo stesso modo i privilegi vengono gestiti dal client. Il server, a secondo dell'account loggato, invia le credenziali che quell'utente dispone su quel file.
Poi sarà il client a "ingrigire" i menù o a darti i messaggi.
Quando ti appare "l'utente non dispone i privilegi per eseguire questa azione" è il tuo client che te lo invia, tant'è che io posso sostituire il messaggio con "dottò lei non può"

[Vash1986]

...bizzarro metodo di condivisione...

Considera che sul client hai una versione pagata e funzionante di FM, ed utilizzano una parte della potenza di calcolo del client per alleggerire il carico sul server e sulla rete, dov'è la bizzarria?

Purtroppo mi è capitato di usare un db filemaker in una azienda dotata di connessione wireless. Il database era composto da una sessantina di file, con un centinaio di script l'uno e decine di migliaia di record. Totale: 400mb.

Alcuni dei pc più lontani prendevano un segnale wireless scarsino e avevano una banda di circa 100k/s verso l'access point. Inoltre uno di questi era un vecchio AMD Athlon 900mhz.

Come funzionava il DB da questa postazione?
1- impiegava 10-20 secondi buoni per aprire un layout che necessitava di 2-3 file.
2- molto spesso si bloccava fino a quasi 1 minuto mandando messaggi del tipo "record non indicizzati ancora da ordinare... 20000"

Per non parlare della gestione della concorrenza... purtroppo capitavano a volte schede clienti con ID duplicato.
Essendo il database composto da centinaia di script, non ho avuto il tempo di indagare se questa scarsità di prestazioni fosse dovuta a pessime scelte progettuali dei creatori o ai limiti di filemaker 5. Se ti va possiamo parlarne. Cmq in modalità singolo-utente su un pc discretamente potente, le cose cambiano completamente e le prestazioni sono eccelse.

Peraltro, in un periodo di larga diffusione di piattaforme a basso consumo basate su Intel Atom, io personalmente sono più propenso all'utilizzo di db query based, perchè il povero atom non ha proprio nulla da offrire in termini di potenza di calcolo, su grossi database almeno. Peraltro l'apertura dell'eseguibile Filemaker su un pc con hard disk 5400rpm e cpu scarsina a volte necessita di qualcosa come una quindicina di secondi.

[stregatto]

connessione wireless. Il database era composto da una sessantina di file, con un centinaio di script l'uno e decine di migliaia di record. Totale: 400mb.

aspetta. se citi FM5 parliamo di un periodo in cui l'unico modo di far girare DB querizzati erano server appositi con apposite installazioni e tempi di sviluppo assai diversi , mentre FM5 era (ed è) un prodotto desktop (e gli OS erano Mac OS9 e Windows 98/2k): non è un paragone fattibile.
Molto conta anche l'abilità di impostazione del tutto. Da come me lo dici non mi sembra impostato in maniera ottimale.
Se invece parli di un sistema post-FM7 impostato su una sessantina di file (magari convertito ex-abrupto da file .fp5), è ovvio che sia lento. Se la sono cercata, visto che la riscrittura in un file singolo (o due/tre, con separzione dati interfaccia e stampe) è fortemente consigliata e con benefici ben definibili in fase di velocità, stabilità e usabilità. Per non parlare del limite del numero di file condivisi contemporaneamente…

.g.