FileMaker in heavy duty omgevingen: grenzen van Filemaker?

[Marsau]

In dialoog met klanten en prospects komt vaak de vraag op in hoeverre Filemaker toepasbaar is een zeer data-intensieve omgevingen of omgevingen met veel gebruikers. De borreltafel-opvatting in deze is dat Filemaker hooguit geschikt is voor kleine tot middelgrote bedrijven, maar dat daarna snel toevlucht moet worden gezocht tot "serieuze" en zware database-pakketten als Oracle, SQL e.d. Ik vraag mij af wat hiervan waar is en wat jullie ideeën hierover zijn.

 

Ik heb onlangs bij een klant een Filemaker oplossing gerealiseerd waarbij geautomatiseerd gegevens worden verzameld (geconsolideerd) uit verschillende databronnen. We spreken nu over een half miljoen records, maar men wenst een uitbreiding waarbij men op weekbasis 40.000 nieuwe records uit XML bronnen zou moeten halen, oplopend tot een database van ca 50 miljoen records. Overigens weinig velden en eenvoudige, voornamelijk getalsmatige informatie. En we verwachten ook weinig gelijktijdige gebruikers van dit systeem. Ik heb nog geen ervaring met dergelijke aantallen records.

 

Geen probleem volgens de specs die Filemaker geeft, maar wat zou dit voor performance betekenen? Gaat een zoekopdracht dagen duren? Moeten ze zo snel mogelijk Oracle personeel gaan inhuren?

 

Zie de techische specificaties van Filemaker (13 overigens):

http://help.filemaker.com/app/answers/detail/a_id/11889/~/technical-specifications-of-filemaker-pro-13-and-filemaker-pro-13-advanced

 

 

Zie ook deze vergelijking tussen Filemaker, SQL en Oracle:

http://db-engines.com/en/system/FileMaker%3BMicrosoft+SQL+Server%3BOracle

 

En dit uitstekende artikel:

http://elbsolutions.com/projects/comparison-ms-access-filemaker-ms-sql-server-report-services-aspx-dot-net/

 

Benieuwd naar jullie kennis en ervaring...

 

Marsau

[Infomatics]

Ik ben nog niet zover gekomen, maar heb een eenvoudige database met 7,5 miljoen records en het zoeken op geïndexeerde velden gaat razend

snel op mijn bescheiden server. ik verwacht niet dat het (veel) trager gaat bij 50 miljoen, maar let goed op dat je de velden die je gebruikt om

te zoeken geïndexeerd houd, anders wordt het traag (maar nog geen dagen)

 

Groet, Ruben

[Felix]

.

6 oktober 2015 aangepast door Gast

[Marsau]

Dank jullie wel.. Goed om te horen; dit geeft vertrouwen. Maar wat maakt de grote jongens 'groot'? Waar ligt volgens jullie een omslagpunt?

 

Dit is echt een kwestie in de dialoog met mijn klant. Ze horen van Filemaker als een "soort MS Access" voor Apple, en geloven niet dat werkelijk zware/krachtige oplossingen mogelijk zijn.

[Felix]

.

6 oktober 2015 aangepast door Gast

[Infomatics]

Wat maakt de grote jongens groot.

 

Ik denk dat dat vooral de mogelijkheid is van veel gelijktijdige gebruikers. Met FileMaker groei je op een begeven moment tegen tegen een plafond aan al heb ik verhalen gezien van mensen die met FileMaker en PHP tienduizenden bezoekers per dag afwikkelden.

 

Groet, Ruben

[hans erik]

Ik denk dat de algemene opvatting dat FMP voor kleine tot middelgrote toepassingen geschikt is, vooral iets is wat uit het verleden is blijven hangen. Maar daarmee wel hardnekkig aanwezig blijft.

 

Dat is natuurlijk niet het hele verhaal. Een FMP database kan gemakkelijk tabellen hebben van een paar miljoen records. Punt is dat dergelijke grote toepassingen ook vaak op andere gebieden 'groter' zijn: spreiding over meerdere locaties, gebruik door tientallen gebruikers tegelijkertijd enzovoorts. Dat zijn wel zaken waar je sneller tegen beperkingen aanloopt die ORACLE en MySQL niet hebben.

 

Als je een FileMaker database van het allereerste begin inricht met (op)schaalbaarheid als uitgangspunt, dan kom je een heel eind.

Wat ontbreekt is dan bijvoorbeeld een optie om twee identieke databases te laten synchroniseren danwel replicatie en meer controle over de caching (als een serverside script bijvoorbeeld een aantal records verwijdert of verandert, zou je een mogelijkheid moeten hebben om bij clients de cache geforceerd te verversen; die mogelijkheid is er nu niet).

 

En FMI geeft wel aan hoeveel data een database kan bevatten, maar officiële performance benchmarks zijn er niet. Dat laatste zou wel helpen denk ik om mensen over de streep te trekken.

[Marsau]

Dank jullie wel.. De grenzen van Filemaker liggen (waarschijnlijk) dus vooral in het aantal gebruikers dat je kan bedienen. Niet zozeer in performance of beperkingen in de sfeer van aantal records en tabellen. De "grote jongens" zijn vooral groot omdat hier meer schaalbaarheid mogelijk is en omdat er specfieke power-voorzieningen zijn om op database-niveau bepaalde taken op te knappen.

 

@Felix: je weet hoe het werkt. Mensen huldigen vaak ongefundeerde meningen. Ik irriteer mij ook mateloos als Filemaker weer eens gepresenteerd wordt als "Access voor Apple", en "slechts geschikt voor kleinbedrijf", maar vind maar eens duidelijke info om ze van repliek te dienen.

[SuperWimmie]

Wat maakt de grote jongens groot?...

 

Vertrouwen.

 

Roep Oracle en iedereen weet dat het een globale speler is met haar databases.

Roep Filemaker en niemand kan vergelijkbare voorbeelden tonen.

 

Qua database kan Filemaker veel hebben.

Qua schermafhandeling en aantallen gebruikers wordt het een ander verhaal.

 

Wat hier al wordt gezegd, een slimme opzet, gebaseerd op geindexeerde velden (kan je heel wat winst mee halen) en een simpel datamodel doen wonderen.

Met het datamodel is ook forse winst te halen. Haal een totaaltelling op via een gerelateerd record en hij is razendsnel.

Idem voor het vinden van de juiste datasets. Gaat via gerelateerde records het snelst, mits de gegevens dit toelaten.

 

Maar jouw probleem is vertrouwen: jouw bazen willen zeker weten geen scheve schaats rijden en gaan af op wat "iedereen" zegt.

Of ze er verstand van hebben, of niet.

Hebben ze verstand van Oracle, dan adviseren ze dat.

Hebben ze geen verstand van Filemaker, dan raden ze dat af.

 

Ik heb hier een tabel met 22,5 miljoen records, 7,8 Gb groot. Geen enkel probleem.

[Ari]

Denk ook eens aan het updaten van je applicatie. Kan het bedrijf even een uurtje (of 2) plat om alle records in te lezen in de nieuwe versie?

 

Snelheid tov sql dbases? Ik heb een gerelateerd postcode bestand liggen tot op het bot genormaliseerd en geïndexeerd. Het opvragen van een combinatie duurt meer dan een seconde. Exact dezelfde opzet in mySQL doet het in 'a blink of the eye'

 

Stabiliteit? Vorige week nog bij een klant FM server opnieuw geïnstalleerd omdat poort vierhonderdnogwat eruit was gegooid en niet meer geactiveerd kon worden.

 

Wil je snel ontwikkelen, veel functionaliteit, een niet zo snelle database en neem je zo nu en dan een spannend avontuurtje op de koop toe dan kies je voor Filemaker.

 

Wil je stabiliteit (en de mogelijkheid tot roll back en load balancing), hoge ontwikkelingskosten en geen verrassingen dan kies je voor Oracle, msSQL, Postgres of MySQL in combinatie met een dotNet ontwikkelomgeving. Een slimme combinatie van FM en SQL is ook mogelijk.

 

Bedenk ook dat een klant jou aansprakelijk kan stellen voor het advies dat jij hebt gegeven dus mijn advies is: laat een ander adviseren...

[hans erik]

Denk ook eens aan het updaten van je applicatie. Kan het bedrijf even een uurtje (of 2) plat om alle records in te lezen in de nieuwe versie?

Data en interface scheiden? Dat maakt wel even uit.