Come funziona filemaker, internamente?

[stregatto]

premesso che evidentemente il DB era fatto con i piedi…

1) non trasferisce "tutti" i record. invia i record richiesti. l'indicizzazione è tutt'altra cosa. evidentemente chi ha scritto il db non aveva una chiara idea di cosa ottenere.

2) no. il client invia una richiesta e il server risponde

3) record locking pessimistico. Quando l'utente A impegna il record, aquesto (e a tutti record correlati secondo il tunneling ) viene preclusa la modifica. questo può essere oggetto di problemi, in DB fatti male.

4) di solito, client.

.g.

[Pirata]

Complimenti!
Questo si che è stato un argomento interessante
se non fosse per qualche fuori programma!

[flavio1917]

premesso che evidentemente il DB era fatto con i piedi…

1) non trasferisce "tutti" i record. invia i record richiesti. l'indicizzazione è tutt'altra cosa. evidentemente chi ha scritto il db non aveva una chiara idea di cosa ottenere.

2) no. il client invia una richiesta e il server risponde

3) record locking pessimistico. Quando l'utente A impegna il record, aquesto (e a tutti record correlati secondo il tunneling ) viene preclusa la modifica. questo può essere oggetto di problemi, in DB fatti male.

4) di solito, client.

.g.

Ciao Stregatto, grazie per le tue informazioni, mi saranno molto utili visto che non ho trovato nessun documento su internet che spieghi come viene gestita la base di dati da filemaker e su come avviene la suddivisione del carico applicativo e la comunicazione tra client e server.

A tal proposito, sapete consigliarmi qualche sito web su cui poter trovare queste informazioni?


Potete spiegarmi meglio cosa avviene quando il server realizza l'indicizzazzione?Perchè tarda tanto tempo?

Ringraziandovi ancora per il vostro supporto online, vi invio i miei saluti!

Flavio

[stregatto]

sul sito di filemaket (technet).
per quanto riguarda l'indicizzazione, è un discorso abbastanza complesso, è non è il server che la gestisce, in quanto è a livello di tabelle e viene gestita quindi a livello di file (sia questo sopitato su server o in monoutenza).
A livello di funzionamento "sotto il cofano" FM crea gli indici per interrogazioni o relazioni, per verifica di unicità o esistenza, per la creazione di Liste valori, per il completamento automatico e per altre cose minori (come il completamento campo dall’indice).
In generale (con qualche eccezione come per il giapponese), FM crea due indici per ciascun campo, uno per parola e un altro per valore, il primo utilizzato per le ricerche, il secondo per relazioni e LV.

Veniamo al lato utente. chi sviluppa il Db può decidere si indicizzare o meno i campi. Un campo indicizzato utilizza maggiore spazio su disco, ma ha una velocità di ricerca o di ordinamento molto maggiore: tutti i campi sono indicizzabili, eccetto i campi contenitore e risaaunto (per ovvie ragioni) e i campi calcolati, che possono essere indicizzati solo se tutti gli elementi del calcolo fanno parte della stessa tabella.
Ergo, mi sembra che l'ordinamento sia basato su un campo calcolato non indicizzato, e quindi il server debba prima ricalcolarsi tutti i campi e poi procedere all'ordinamento. ri-ergo, mi ha l'aria di un DB sviluppato con un parte del corpo normalmente deputata ad altro.

.g.