File structuur FileMaker

[andries]

we hebben hier een discussie over hoe je het beste een FileMaker applicatie kan opstarten, we geraken er niet uit, dus gooien we het maar publiek Het gaat om het gebruik van het aantal files, en data/interface separatie. Het gaat niet om de ontwikkelingssnelheid of het gemak om een nieuwe versie te deployen, maar wel om de performantie van de applicatie zelf.

 

Ik ben er zelf van overtuigd dat je het beste een data file maakt, en dan een interface file per consumer (iOS, Pro, WebDirect, ...), zodat een iOS niet moet inladen wat een Pro file moet weten (vaak complexere portalen, relaties etc). Ook voor webdirect zie ik hier voordelen, omdat je vaak een heel simpele data file hebt, en voor webdirect simpele interface file.

 

De discussie gaat vooral over WAN performance. Het argument wordt opgeworpen dat over WAN het openen van een tweede file langer zou duren... en dat in het algemeen een "multi-file" oplossing trager draait dan een single file. (op zich logisch, maar hoe zwaar weegt dit door)

 

Als iemand hier advies/bemerkingen op heeft, graag

[Felix]

.

5 oktober 2015 aangepast door Gast

[andries]

nerdy, nerdy...

 

Ik zie dit bijvoorbeeld aan een zeer simpel webdirect onderdeel in een anderzijds zeer complexe toepassing van mijzelf. Alleen die scriptstappen, lay-outs en berekeningen die je vanaf openen tegenkomt voor het opbouwen van het scherm worden bepaald, waardoor het resultaat nog redelijk vlot op het scherm komt. Of het dan om een iOS, webdirect of FM onderdeel gaat doet naar mijn idee niet terzake.

 

Dit vind ik een zeer interessante opmerking! Heb je aparte TO's gemaakt voor je webdirect toepassing of zijn die TO's gebaseerd op dezelfde TO's alswaar je PRO layouts op gebaseerd zijn? Wat ik probeer te achterhalen is of FileMaker intelligent genoeg is om enkele de relaties in te laden die hij nodig heeft, of elke relatie die aan de TO hangt (en dus die niet worden gebruikt op de huidige layout, zijnde portaal of calculatie die gebruikt maakt van de relatie).

[Felix]

.

5 oktober 2015 aangepast door Gast

[WJ]

Hoi,

 

Ik denk dat het van belang is te beseffen dat filemaker een cache per bestand bijhoudt. Als je een factuurmodule maakt met een factuur tabel en factuurregels tabel. Je maakt deze structuur in een single file en in een interface/data file dan zul je verschil zien in caching. In een single file kan je een factuurregel toevoegen en op het moment dat je het bedrag invult zie je meteen het totaal bedrag updaten (sum van de regels). Doe je datzelfde in een multifile dan heb je refresh problemen.

 

Bij het openen van een bestand loopt filemaker de grafiek af en maakt een cache per join aan. Dat doet hij voor alle relaties. Je zult zien dat als je een grote graph (1000+) hebt dit een behoorlijke performance druk legt op de applicatie, tot zelf niet meer functioneren. Het scheiden van de graph in verschillende bestanden levert dan ineens een veel snellere applicatie op. Maar levert dan weer refresh problemen op. Dus ja het is kiezen. Maar een kleine graph zorgt voor meer snelheid in je app.

 

Over het wan is de hoeveelheid data erg belangrijk voor de snelheid. Daarom zie je soms dat men aan table narrowing doet.

 

Groet,

 

WJ

[andries]

Dit kun je bijvoorbeeld zien wanneer je een tabel met heel wat records hebt waar je een relatie naar hebt die op een ongeïndexeerd veld moet sorteren. De sort wordt pas uitgevoerd wanneer iets via die relatie op het scherm gezet moet worden of in een script of te berekenen resultaat gebruikt wordt. Dus niet wanneer er nog geen reden is om dat alvast uit te voeren. Dus ik denk dat FM die intelligentie die je noemt inderdaad heeft.

 

He Felix,

mijn ondervinding hierbij is dat FileMaker twee soorten relaties heeft: geindexeerde en niet geindexeerde relaties, en dat FileMaker hier inderdaad anders mee omgaat. Ik denk (en het is ook niet meer dan dat) dat FileMaker bij het openen van een layout al de geindexeerde relaties gaat inladen (in cache) die vertrekken vanop de TO waarop je layout is gebaseerd, en dat niet geindexeerde relaties enkel worden uitgevoerd indien nodig. Deze discussie zou echter leiden naar een vergelijking of Anchor-Buoys al dan niet performanter zou zijn dan een datamodel waarbij alles aan elkaar is gelinked (en dus filemaker bij het inladen al alles inlaadt), en niet perse naar Data/Interface separatie.

 

Wat ik wel begrijp is dat je Webdirect applicatie (hoewel in dezelfde file) niet echt "gelinked" is met je Pro applicatie, en een aparte plaats heeft gekregen in je Entity Relation Diagram, en dus blijkbaar enkel inlaadt wat hij nodig heeft. Ik vermoed dat hij de cartesian relatie enkel zal gebruiken indien nodig.

[andries]

Bij het openen van een bestand loopt filemaker de grafiek af en maakt een cache per join aan. Dat doet hij voor alle relaties. Je zult zien dat als je een grote graph (1000+) hebt dit een behoorlijke performance druk legt op de applicatie, tot zelf niet meer functioneren.

wel, dit weet ik dus niet of het helemaal waar is, ik denk dat FileMaker enkel maar de relaties cached gelinked aan TO's waar je bent gepasseerd. Ik ben hier niet zeker van, maar het verklaart wel waarom Felix's webdirect toepassing zeer performant draait in een complex PRO applicatie.

 

Ik denk dat het van belang is te beseffen dat filemaker een cache per bestand bijhoudt.

Zeer interessant! Maar wat zit in die cache dan? Als je een interface/data separatie hebt, heb je dus in de cache van je data file je records zitten, maar wat zit dan in de cache van de interface?

 

 

Maar een kleine graph zorgt voor meer snelheid in je app.

dat is zeker

[WJ]

Hoi Andries,

 

Dit wordt een beetje gokken en begeef me dus op glad ijs. Maar de volgende punten:

Een bestand met veel occurences opent een stuk langzamer. Zeker als ze allemaal verbonden zijn en dus niet in met het ancher en buoy. FileMaker heeft dan veel werk met het aanmaken van de cache data.

Als FileMaker alleen de joins zou cachen die hij tegenkomt met opstarten door de 'layouts' dan zou er niet zo'n groot verschil mogen zitten tussen bestanden met een grote grafiek en een kleine. Walking the graph heb ik andere ontwikkelaars dit fenomeen ook wel horen noemen. Voorbeelden van bestanden die 5 minuten duur voordat ze openen omdat de grafiek zo groot is zijn bekend.

Caching verandert zo'n beetje in iedere versie van FileMaker en wordt steeds verder geoptimaliseerd.

We hebben het hier over de joint cache. Die je kunt legen met flush cache join results(refresh window). Dit zijn de joins van de relaties. Andere informatie zoals layout info wordt ook gecached. Hoe het precies werkt met meerdere bestanden weet ik niet precies.Dat het refresh problemen oplevert dat weet ik wel. FileMaker probeert automatisch de cache bij te werken als data verandert dit lukt niet altijd even goed. Zeker niet met meerdere bestanden. Dit kan je eenvoudig uittesten. Er zit dus verband tussen meerdere bestanden en caching. FileMaker heeft minder goed door wanneer hij de join cache van de interface file moet bijwerken. Ik denk dat FIleMaker de externe koppeling met bestanden meer erin heeft gezet om toen der tijd backwards compatible te zijn (Conversie van fp5->fp7). Maar ja het lonkt wel om te gebruiken voor allerlei doeleinde. Maar het heeft een hoge prijs als je het mij vraagt.

 

Groet,

 

WJ

[Vitruvius]

Ik weet in elk geval zeker dat filemaker pas zaken begint in te laden en te berekenen wanneer dit nodig is.

Concreet 1: er is een externe tabel die in slechts enkele gevallen benaderd moet worden. Stel de link is verbroken (serververbinding off line of zo iets). Pas wanneer die externe tabel nodig is zal filemaker deze opzoeken en dan pas tot de constantie komen dat de link verbroken is.

Concreet 2: een enorme grafiek staat op een tabblad. Die grafiek zal pas worden gegenereerd wanneer de desbetreffende tab op de voorgrond komt.

Dus achtergrond data die niet nodig is zal niet worden aangemaakt. Een afgeslankte versie omdat er data niet nodig is heeft dus weinig performantievoordeel indien dat de reden zou zijn.

[hans erik]

Hmm, interessante discussie.

 

Ik ben een groot voorstander van het separatiemodel. Het geeft je als ontwikkelaar een veel grotere flexibiliteit in het inrichten van de juiste architectuur.

Voor een klant heb ik bijvoorbeeld 1 datafile en 3 interface files: één voor de lokale desktops, met de hele functionaliteit, één afgeslankt bestand speciaal voor iPads die via een WAN verbinding connecten en één voor een IWP interface, waar derden via een browser aanloggen, met heel beperkte functionaliteit en een heel strikt toegangsregime.

Als ik de desktop oplossing via internet open, duurt dat 35 seconden. Dat is best een complex database schema met een paar honderd TOC's, scripts en layouts.

De iPad versie is veel kleiner en doet er maar 12 seconden over. In beide gevallen wordt dezelfde datafile geopend.

 

 

Wat betreft de caching van relaties en gerelateerde TO's, ik vraag me af of FileMaker 'one-directional' relaties (een global veld als foreign key) qua caching anders behandelt dan 'bi-directional' relaties (een 'echt' veld als foreign key). Iemand daar een idee over? Hoe zou je dat kunnen vaststellen?

 

Ik heb overigens bij FMI een feature request ingediend om het database schema optioneel semi-transparant te maken. D.w.z. dat je TO's via een 'one-directional' relatie grijs of anders gekleurd weergeeft, of zelfs weg kunt filteren in de keuzelijsten voor formules e.d.

Een soort 'don't show one-directional relations' checkbox dus.

 

Ik gebruik ook - in de user-file - 'one-directional' relaties die uit één of meer global en één of meer 'echte' velden als foreign key bestaan. Die zouden dan ook semi-transaparant worden.

[hans erik]

Hoi Andries,

 

 

We hebben het hier over de joint cache. Die je kunt legen met flush cache join results(refresh window). Dit zijn de joins van de relaties. Andere informatie zoals layout info wordt ook gecached. Hoe het precies werkt met meerdere bestanden weet ik niet precies.Dat het refresh problemen oplevert dat weet ik wel. FileMaker probeert automatisch de cache bij te werken als data verandert dit lukt niet altijd even goed. Zeker niet met meerdere bestanden. Dit kan je eenvoudig uittesten. Er zit dus verband tussen meerdere bestanden en caching. FileMaker heeft minder goed door wanneer hij de join cache van de interface file moet bijwerken. Ik denk dat FIleMaker de externe koppeling met bestanden meer erin heeft gezet om toen der tijd backwards compatible te zijn (Conversie van fp5->fp7). Maar ja het lonkt wel om te gebruiken voor allerlei doeleinde. Maar het heeft een hoge prijs als je het mij vraagt.

 

 

Misschien heb je gelijk maar dat geldt dan toch alleen als je portalrows filtert. Ik zie eerlijk gezegd geen problemen optreden bij normaal gebruik: je verandert een foreign key en de portal wordt direct ververst. Volgens mij is het niet zo dat FileMaker bij een gescheiden model twee aparte caches aanhoudt en dus in verwarring raakt. Ik denk namelijk dat er voor het databestand helemaal geen Join cache wordt bijgehouden, alleen voor het interface bestand.

[rgaros]

Ik ben een groot voorstander van het separatiemodel. Het geeft je als ontwikkelaar een veel grotere flexibiliteit in het inrichten van de juiste architectuur.

Maar het maakt de database wel complexer en wordt ook niet door FM ondersteunt. Ooit er al eens een vraag over gezien op het examen?

Volgens mij een leuke techniek uit de tijd van trage modems maar met de huidige verbindingen niet meer zinvol.

 

Bovenal, de interface is -tenzij je 7 Mb foto's erin gebruikt- geen enkel probleem voor FM en ze doen steeds beter hun best om alleen tijd te besteden aan objecten die nodig zijn (bravo!). Het probleem is de data, daar heb je er meer van en als je gaat sorteren op gerelateerde velden, zoeken op niet geïndexeerde velden, merendeels niet-opgeslagen berekeningen enz. dan krijg je elke database tot stilstand. Daarmee zorgvuldig omgaan en verdiepen in optimalisatie levert je m.i. veel meer voordelen op.

 

Ik heb een eigen database van 2 Gb met 35 Gb externe data, 124 tabellen, max 150 velden per tabel en relaties zoveel mogelijk in een hiërarchische boomstructuur. Loopt als een trein op Mac, Win, iOS (ook 4G, wel eigen layouts vanwege schermafmetingen) en webdirect. Lekker alles in één database zodat wijzigingen voor alle platforms realtime wordt doorgevoerd. En die 2 Gb komt echt niet in zijn geheel over de 4G verbinding als ik de database op een iPhone open...

Ook voor klanten heb ik nooit anders gedaan, wo. een tabel met bijna 800.000 records en 100 velden. Of een database die sinds de oplevering in 2007 een vijftal tabellen kreeg met rond de 200.000 records, draaide nogsteeds zonder enige noodzakelijke aanpassing. Tevens een demo-database van 15 miljoen records, data en structuur in één bestand.

 

Mvg,

René

[Infomatics]

Beste René,

 

Systemen verdelen in verschillende modules kan voordelen hebben, zo heb ik een systeem van in totaal zo'n 2 gig verdeeld over Adressen/Servicebonnen/Prijslijsten/Facturen & Planning. Door het systeem in blokken te verdelen worden de relatie diagrammen niet zo gruwelijk groot, en is het aantal tabellen en records per module beperkt, waardoor een import in een clone minder tijd kost. Ook hoef ik de prijslijsten niet de hele dag te backuppen (800 mb) omdat die toch maar 1 x per maand worden bijgewerkt.

 

Groet,

 

Ruben

[rgaros]

Systemen verdelen in verschillende modules kan voordelen hebben, zo heb ik een systeem van in totaal zo'n 2 gig verdeeld over Adressen/Servicebonnen/Prijslijsten/Facturen & Planning.

 

Zeker, maar dan vooral omdat het andersoortige informatie is met mogelijk andere gebruikers. Nadeel vind ik nl. dat je wel een externe relatie kan leggen maar dan volstaat niet één TO, je zal het hele/halve schema van de externe database opnieuw moeten aangeven (en bijhouden!)...

 

Ook hoef ik de prijslijsten niet de hele dag te backuppen (800 mb) omdat die toch maar 1 x per maand worden bijgewerkt.

Dan zeg ik: harde schijf van 2 Tb, who cares.

De back-up van 58 Gb aan FM en externe bestanden duurt 11 minuten. FMS noteert de bestanden als ongewijzigd als ze inderdaad niet gewijzigd zijn en zodoende gaan ze desgewenst niet in de normale backup mee.

 

Mvg,

René

[Felix]

.

5 oktober 2015 aangepast door Gast

[Infomatics]

Systemen verdelen in verschillende modules kan voordelen hebben, zo heb ik een systeem van in totaal zo'n 2 gig verdeeld over Adressen/Servicebonnen/Prijslijsten/Facturen & Planning.

 

Zeker, maar dan vooral omdat het andersoortige informatie is met mogelijk andere gebruikers. Nadeel vind ik nl. dat je wel een externe relatie kan leggen maar dan volstaat niet één TO, je zal het hele/halve schema van de externe database opnieuw moeten aangeven (en bijhouden!)...

 

Ook hoef ik de prijslijsten niet de hele dag te backuppen (800 mb) omdat die toch maar 1 x per maand worden bijgewerkt.

Dan zeg ik: harde schijf van 2 Tb, who cares.

De back-up van 58 Gb aan FM en externe bestanden duurt 11 minuten. FMS noteert de bestanden als ongewijzigd als ze inderdaad niet gewijzigd zijn en zodoende gaan ze desgewenst niet in de normale backup mee.

 

Mvg,

René

 

Door de verschillende taken in de verschillende modules af te wikkelen staan de modules aardig op zichzelf en zijn er maar een beperkt aantal verbindingen nodig tussen de modules. Zo zit alles wat met factureren/betalingen/maningen te maken heeft in de module Facturen, en heeft die 1 link naar de adressen voor de benodigde adres gegevens. etc.

 

Groet,

 

Ruben

[rgaros]

Door de verschillende taken in de verschillende modules af te wikkelen staan de modules aardig op zichzelf en zijn er maar een beperkt aantal verbindingen nodig tussen de modules. Zo zit alles wat met factureren/betalingen/maningen te maken heeft in de module Facturen, en heeft die 1 link naar de adressen voor de benodigde adres gegevens. etc.

 

Hoe zelfstandiger de data is, hoe makkelijker het in een aparte database te stoppen is. Maar daar zitten wel een paar nadelen aan zoals wachtwoorden maar als het een alleen-lezen is kan je alleen gasttoegang geven.

De 2Gb database die ik noemde heeft eigenlijk alle grote, middelgrote en kleine tabellen die nauw met elkaar verweven zijn. Een paar hele grote databases ter raadpleging zoals Geonames, Weerdata en Rijksmonumenten staan geheel los. Die wijzigen ook zelden en vormen nauwelijks een belasting voor de back-up.

 

Overigens, en dit is een nostalgisch grapje, moest ik denken aan de Commodore 64. In die tijd had ik in basic een programma geschreven dat niet in één keer in het geheugen pastte. Daarom subprogramma's gemaakt die elkaar naadloos openden.

 

Mvg,

René

[hans erik]

Een nadeel van meerdere bestand is het accountbeheer. Je moet dat per bestand regelen. De situatie tot aan FM6 waarin elke tabel zijn eigen bestand had was wat dat aangaat een bezoeking. De enige oplossing was, is om daar dan weer een hele set procedures omheen te scripten.

 

Dat klopt. Dat is inderdaad lastig maar eigenlijk alleen bij WebDirect en IWP, omdat je daar de client niet als Guest kunt laten aanloggen aan de userfile. Ik laat nomaliter de gebruiker altijd als guest aanloggen aan het userbestand. En ik moet erbij zeggen dat ik geen ervaring heb met externe authenticatie (OpenDirectory of iets soortgelijks).

 

Nu we toch bezig zijn wil ik nog wel even een paar andere voordelen noemen ( maar niet iedereen zal die als voordelen zien):

 

1. Je hoeft in een productieomgeving eigenlijk nooit meer een import van data naar een nieuwe versie te doen. Mijn ervaring is dat op een gegeven moment pakweg 99,9% van de modificaties aan de user file gebeurt (layouts, scripts, keuzelijsten, TO's etc). De datafile verandert alleen zelden van structuur. Komt er een tabel bij of een paar velden, dan kun je dat buiten kantooruren even on-line doen en als het echt ingewikkeld wordt haal je daarna de backup over zodat je eigen omgeving weer 100% identiek is.

Ik heb bij een klant een database destijds naar FMP10 geconverteerd en nadat ik de boel had opgeschoond zijn de data nooit meer omgezet naar een ander bestand (wel naar FMP12 uiteraard).

 

2. Je kunt je ontwikkelomgeving gemakkelijk switchen van de ene datafile naar de andere: één filereferentie aanpassen en klaar is kees. Bijvoorbeeld een testomgeving. Overigens moet je er wel voor zorgen dat er alleen een referentie van de userfile(s) naar de datafile gaat, NIET ANDERSOM. Anders worden het FileMaker 6 toestanden.

 

3. Je wordt als ontwikkelaar gedwongen om goed na te denken over de structuur van je database: welke relaties zijn essentieel voor je datadefinitie (= het business model) en wat is eigenlijk bedoeld voor de interface (window dressing)? Het schema van zo'n datafile ziet er best simpel uit, terwijl de userfile heel complex oogt.

 

Er zit ook een auteursrechtelijk aspect aan: een klant is feitelijk eigenaar van 'zijn data', terwijl jouw slimmigheden als programmeur voor een groot deel in de userinterface (scripts, layouts) zijn ondergebracht.

 

Maar het maakt de database wel complexer en wordt ook niet door FM ondersteunt. Ooit er al eens een vraag over gezien op het examen?

 

Nee, en in de hele documentatie van Soliant Consulting wordt met geen woord gerept over het separation model, en worden externe koppelingen sowieso nauwelijks behandeld. Dat vind ik erg onprofessioneel, want het is juist iets waar mensen wel een steuntje in de rug kunnen gebruiken.

 

Overigens: het is niet mogelijk om een externe referentie via een scriptstap aan te passen. Waarom niet? Logisch, want dan zou de helft van de FileMaker Server business verdampen. Je zou dan dynamisch van datafile kunnen switchen.

[hans erik]

Over die complexiteit: ik denk dat een separated model per saldo nauwelijks complexer is dan een model waarbij alles in één bestand zit. Bij elke grotere database komen meerdere TO's voor die naar dezelfde base table verwijzen. Dat betekent dat je bij berekeningen van gerelateerde velden altijd uit moet kijken welke context je kiest. Bij een 'geïntegreerde oplossing' is het aantal mogelijke contexts veel groter omdat alle TO's in hetzelfde schema zitten. In een aparte datafile is het aantal mogelijke contexts veel kleiner, dus er is wel degelijk een positieve trade-off. Voor de performance maakt het denk ik niks uit, behalve bij een matige dataverbinding, dan zou je kunnen overwegen de userfile bij de client neer te zetten. Heb je wel weer een onderhoudsprobleem erbij.

 

[Edit]:

Maar het maakt de database wel complexer en wordt ook niet door FM ondersteunt. Ooit er al eens een vraag over gezien op het examen?

 

 

Nee, en in de hele documentatie van Soliant Consulting wordt met geen woord gerept over het separation model, en worden externe koppelingen sowieso nauwelijks behandeld. Dat vind ik erg onprofessioneel, want het is juist iets waar mensen wel een steuntje in de rug kunnen gebruiken.

 

In de Training Course wordt het seperation model in hoofdstuk 2 wel behandeld. Dit klopt dus niet.

HE

[rgaros]

1. Je hoeft in een productieomgeving eigenlijk nooit meer een import van data naar een nieuwe versie te doen.

Bij single-file ook niet. En voor die ene keer dat het wel nodig is, is dat tegenwoordig heel goed te scripten m.b.t. field-matching. Daarbij kan je ook gemakkelijk aanpassingen op de veldinhouden doen en uitgebreid offline testen.

Lokaal op een beetje snelle computer (met SSD) is dat praktisch voor de meeste databases heel goed te doen. Overigens, niet alleen het aantal records is van belang voor de snelheid maar ook het aantal velden. Tijdens het schrijven een extreem testje gedaan: 998.000 records met 46 data-velden in 20 minuten op MacBook Pro 2.7 Ghz.

Lang geleden een bibliotheeksysteem gemaakt die een hele nacht deed over minder records. FM5, PowerPC. Was een van mijn weinige data-separation projecten omdat het in drie bibliotheken van dezelfde hogeschool wordt gebruikt.

 

3. Je wordt als ontwikkelaar gedwongen om goed na te denken over de structuur van je database: welke relaties zijn essentieel voor je datadefinitie (= het business model) en wat is eigenlijk bedoeld voor de interface (window dressing)? Het schema van zo'n datafile ziet er best simpel uit, terwijl de userfile heel complex oogt.

Nadenken is altijd handig.

Maar data TO's moeten wel dubbel gemaakt worden (bv. als je gerelateerde velden wilt gebruiken in berekeningen) en daarna bij wijzigingen in beide bestanden aangepast worden. En dat vergeet iedereen wel eens terwijl de gevolgen best groot kunnen zijn.

 

Er zit ook een auteursrechtelijk aspect aan: een klant is feitelijk eigenaar van 'zijn data', terwijl jouw slimmigheden als programmeur voor een groot deel in de userinterface (scripts, layouts) zijn ondergebracht.

Script om de kale data te kunnen exporteren? En de klant geen toegang tot de structuur te geven (evt. wachtwoord bij notaris om andere reden) is sowieso handig i.v.m. aansprakelijkheid door wijzigingen. De meeste klanten kunnen die slimmigheden niet doorgronden en vaak zijn ze zo specifiek dat ze voor anderen ook niet van nut zijn, behalve de Eigen Functies.

 

Maar het maakt de database wel complexer en wordt ook niet door FM ondersteunt. Ooit er al eens een vraag over gezien op het examen?

Nee, en in de hele documentatie van Soliant Consulting wordt met geen woord gerept over het separation model, en worden externe koppelingen sowieso nauwelijks behandeld. Dat vind ik erg onprofessioneel, want het is juist iets waar mensen wel een steuntje in de rug kunnen gebruiken.

De woorden professioneel en amateur werken bij mij als een rode lap op een stier, die woorden komen niet in mijn woordenboek voor omdat wel/geen betaling niets zegt over de kwaliteit van het werk.

Externe koppeling kan juist kort behandeld worden omdat het na plaatsen van TO verder bijna hetzelfde werkt als de interne tabellen. Heel mooie en eenvoudige toepassing van een best lastig abstract ding.

 

Het examen is gebaseerd op FTS (13) en daarin blijkt mij nu een aparte paragraaf over 'Data Separation Model' aanwezig te zijn. Daarin worden een aantal 'common-use' gevallen als uitzonderingen beschreven. Ook gaan ze vooral in op het gebruik van FM voor standaardsoftware waarbij de ontwikkelaar de interface-file verspreidt als update van de database. En principieel ben ik van mening dat de kracht van FM ligt in het feit dat je er maatwerksoftware mee kan maken en het misbruik is om er standaardsoftware mee te maken. Kies dan voor iets anders dan FileMaker...

Er is ook databasesoftware die volledige data separation ondersteunt(de?), weet niet of ik de naam hier mag noemen? Als je daarin een nieuw veld maakt wordt die automatisch toegevoegd in elke datafile waar je het mee gebruikt. Maar daardoor kan je velden nooit meer verwijderen. In de datafile zit echt alleen maar data en geen berekeningsvelden of het relationele schema (vergelijkbaar met SQL/PHP). Dat soort zaken horen volgens mij bij 'volledige ondersteuning' en dat doet FM niet.

Als je berekeningsvelden alleen in de interface-file zou gebruiken (dat idee had ik altijd bij data-separation in FM) zijn ze per definitie niet-opgeslagen en wordt het erg traag...

 

Overigens: het is niet mogelijk om een externe referentie via een scriptstap aan te passen. Waarom niet? Logisch, want dan zou de helft van de FileMaker Server business verdampen. Je zou dan dynamisch van datafile kunnen switchen.

Maar wellicht vooral omdat de gebruiker dan te gemakkelijk een bestand zou kunnen aanwijzen die geheel anders is in structuur?

 

Leerzame en leuke discussie dit, dank daarvoor. Ik weet nu beter wat mijn standpunt is en de verschillen met anderen:

Met zowel bv. multi-files als data-separation hanteer ik de gedachte "niet doen tenzij". Terwijl voorstanders van data-separation het motto "altijd behalve als" lijken te hebben en misschien wel "altijd".

Persoonlijk denk ik dat mijn gedachte het best bij FileMaker aansluit en mezelf en mijn klanten het meeste biedt tegen de laagste investering. De meeste ontwikkelaars gebruiken geen data-separation en dat lijkt mij een goede zaak.

 

Mvg,

René

[hans erik]

Toch nog even terugkomen op de oorspronkelijke vraag van Andries: het ging eigenlijk vooral over de snelheid van opstarten over een WAN (=Internet) verbinding, in utopia oneindig snel maar in deze wereld helaas nog variërend naar budget, plaats en tijd: kun je door het scheiden van data en interface voordelen behalen die zich vertalen in een snellere opstarttijd?

Bijvoorbeeld: iemand met FileMaker Go over een 3G verbinding laadt dan 2 bestanden in plaats van één. Maar doordat het databestand vrijwel geen layouts en scripts bevat en het interface bestand alleen de voor zijn platform benodigde interface, is de gedeelde oplossing per saldo sneller.

 

Mijn ervaring is, dat een toepassing met een kleinere interface file inderdaad sneller laadt dan een toepassing met een grote interface file, gebruikmakend van dezelfde datafile.

En als het echt noodzakelijk is om met een heel grote interfacefile over een WAN verbinding te werken, kun je door het lokaal zetten van de interface file een nog grotere performance winst halen. Is de zaak eenmaal opgestart, dan zal het niet zoveel uitmaken (ofschoon ik denk dat een iOS apparaat eerder 'kortademig' wordt bij een grote interface file; je kunt immers geen cache instellen).

 

Wat eigen timings om dit te ondersteunen:

- grote userfile 51 MByte, kleine userfile 10 MByte, datafile 360 MByte (plus RC folders natuurlijk, maar dat telt in dit verband niet mee)

- openen over WAN duurt 1' 25" bij de grote userfile, 25" bij de kleine userfile, dus zeg maar ongeveer evenredig aan de grootte van het interface bestand (scripts + layouts)

- ter vergelijking: als ik de grote userfile lokaal zet en de datafile open over WAN, opent het bestand in 12".

 

Wat betreft Webdirect: ik heb daar nog geen echte ervaring mee, maar een WebDirect sessie draait natuurlijk altijd op de server zelf. De enige winst behaal je door de layouts simpel te houden, omdat dat de processing van de webpagina's beperkt houdt.

31 mei 2014 aangepast door Gast

[Felix]

.

5 oktober 2015 aangepast door Gast

[hans erik]

Ik vraag me af of je wat dit betreft veel winst kunt halen uit een installatie met twee servers:

- een machine doet de database en handelt de FMPro clients af

- een andere machine handelt alleen WebDirect af.

[rgaros]

Mijn ervaring is, dat een toepassing met een kleinere interface file inderdaad sneller laadt dan een toepassing met een grote interface file, gebruikmakend van dezelfde datafile.

Om te bepalen of veel of weinig interface-data van enige invloed op het laden is, heb ik het volgende experiment gedaan:

 

Testopstelling:

Mac Mini 2,5 Ghz met FMS13

WiFi

FM bestand is 2,12 Gb groot met kloon (structuur) van 14,9 Mb (opmaak is pre-FM13 dus zonder thema’s en dus omvangrijker en trager)

Dit bestand gekozen omdat het het bestand is met de omvangrijkste structuur en een meetbaar verschil zou moeten opleveren.

 

Twee testdatabases:

Het bestand tweemaal gekopieerd (zonder externe data) en beide kopieën aangepast:

- startscript uit te schakelen

- in Bestandsopties ingesteld te openen met een layout (de omvangrijkste zodat er wel wat tijd te meten is)

• 238 Normale velden (wo. 1 containerveld met externe data)

• 3 Samenvoegvelden

• 60 Groepsknoppen

• 14 Portalen

• 3 Tabbladbesturingselementen (genest)

• 17 Grafische objecten

• 6 Web Viewer-besturingselementen

• 1 Grafieken

Een van de twee kopieën geheel ontdaan van lay-outs (behalve waarmee geopend wordt) en scripts.

Invoerlijsten, Eigen functies en Relaties onaangeroerd gelaten omdat het ontbreken ervan invloed kan hebben op de gebruikte lay-out.

De data is intern maar daar wordt in het experiment geen verschil in gemaakt.

 

Elimineren invloeden:

Gewacht tot progressive backup geheel voltooid was.

Geen enkele andere database open

Geen andere gebruikers aanwezig.

Minimaal ander netwerkgebruik.

Geopend via lokaal IP-adres, niet extern IP-adres over de router

Door de aanpassingen waren beide al minstens één keer geopend en mogelijk deels gecached.

 

Test:

Met beide bestanden geoefend in het meten van de tijd

- vanaf indrukken OK knop in het venster voor invoeren van de accountnaam

- tot verschijnen lay-out

 

Waarnemingen:

Met elke versie van het bestand drie waarnemingen gedaan.

Volledige interface: 2,48/2,93/2,63 sec.

Minimale interface: 2,43/2,55/2,40 sec.

 

Het minimale bestand lijkt een heel klein beetje sneller te laden maar dit is volgens mij binnen de onnauwkeurigheid van het meten.

 

Conclusie:

Geen verschil in laadtijd tussen een database met veel lay-outs en scripts en een database zonder lay-outs en scripts.

Gezien het feit dat 'Relaties' in Definieer Database daarna nog enige tijd nodig heeft om te verschijnen, worden ook die niet geladen bij het openen van de database en heeft het aantal relaties geen invloed op de laadtijd.

 

Graag verneem ik graag punten die ik over het hoofd heb gezien. Of de resultaten van andere experimenten.

 

Mvg,

René

[hans erik]

René,

 

misschien moet je de test herhalen over een WAN verbinding? En daarna ook een iPad gebruiken over een 3G verbinding. Dan worden de verschillen wel zichtbaar denk ik.

Als je lokaal werkt is er natuurlijk praktisch geen verschil.

 

FileMaker Inc zit gelukkig niet stil en bij elke versie wordt gesleuteld aan de taakverdeling tussen client en server, en de caching. Ik heb echter de indruk dat de FileMaker Pro client bij het openen van een bestand nog steeds een heel groot deel van de layouts en scripts in het geheugen laadt; plus de data die aanvankelijk nodig zijn.

 

Dus als je opstartscript geen wilde dingen doet en het openingsscherm bevat geen portals met honderden gerelateerde records, is de vertraging door het ophalen van data gering.

 

HE