Wat werkt het snelst

[se7en]

Werk Filemaker sneller als je verschillende databases maakt die aan elkaar gekoppeld zijn of is het sneller als je alles in 1 bestand, in verschillende tabellen onderbrengt.

[Gido_]

Ik denk niet dat men een nieuw systeem gaat toepassen als het trager zou werken

Maar "weten" of het echt sneller is, doe ik ook niet...

Als er geen andere technieken bij te pas zouden komen in FM7 tgo FM6 dan dat, vermoed ik dat het geen verschil zou maken, of zeker niet trager zou zijn.

 

"meten is weten"

[AvD]

Ik denk niet dat men een nieuw systeem gaat toepassen als het trager zou werken

 

Ahum! Ahum! Ahum!

[Gido_]

Ik had zo al een voorgevoel dat ik mij hier buiten moest houden

 

In het algemeen ben ik onmiddellijk akkoord (wat allerlei betreft in de wereld). Maar bedoel je dat de tables op zich "zeker niet sneller" zijn dan aparte files, om het diplomatisch te houden?

 

"Geen antwoord" zal ik ook als diplomatisch beschouwen in dit geval

[AvD]

We zullen het objectief houden: ik heb - echt waar - Mac-gebruikers horen klagen over de snelheid van FM7 en dat dit flink onder die van de vorige versie zou liggen. Nu, een tijd later, hoor ik die klachten niet meer. Ik weet niet waarom.

Voor gigantisch grote databanken spreek ik me helemaal niet uit op dit forum. Anderen zijn daarvoor beter geplaatst.

[se7en]

We zullen het objectief houden:

 

De databank waarmee ik momenteel bezig ben zal ongeveer 60 tabellen bevatten. Is het beter dit te splitsen.

Vele van deze tabellen bevatten niet zoveel gegevens maar er zijn er wel enkele bij zoals mijn datatabel die ik gebruik voor levering, bestelbon en facturatie die in de toekomst toch wat kunnen aangroeien.

[AvD]

Voor zover ik weet, kan je de tabellen rustig in één file behouden. Mag geen probleem geven.

[Rony Rabijns]

We zullen het objectief houden: ik heb - echt waar - Mac-gebruikers horen klagen over de snelheid van FM7 en dat dit flink onder die van de vorige versie zou liggen.

 

Klopt !

De motor van 7 is weliswaar merkelijk sneller dan die van 6, maar het aansturen van de printerdriver en het weergeven van een "complexere" grafische interface is dan weer beduidend trager dan in 6.

[Koen Van Hulle]

Bedenk ook: het is makkelijkere later data tabellen te splitsen in verschillende bestanden dan ze achteraf samen te brengen in één bestand.

 

Koen

[RON7]

Lijkt me toch makkelijker om bovengenoemd bestand (inkoop,bestelling,fakturatie) uit te splitsen in enkele bestanden.Vind ik persoonlijk handiger en stukken sneller om nadien te rapporteren...en daarom gebruiken we toch immers Filemaker

[Bonte]

Ik splits data en frontend maar een verschil in snelheid heb ik voorlopig nog niet opgemerkt.

 

Op Mac werkt FM 7 wel veel trager dan versie 6 maar dat ligt voornamelijk aan osX denk ik. In de 7 is het ook verleidelijk om veel vertragende relaties te leggen, het werkt zo makkelijk

 

Wel redelijk wat last gehad tussen relaties en scripts, het gebeurt regelmatig dat het script te vlug gaat om relaties te kunnen leggen en dan werkt er maar de helft. Ik moet dus telkens eerst de relatie bevestigen met een (goto field 'select') en dan werkt het perfect.

[Arnoud]

Aangezien ik nog een aantal Gigs ter beschikking had heb ik getest of een portal die (10.000) records toont uit een tweede database trager is dan een portal die het zelfde aantal records toont uit een tweede tabel (van dezelfde database).

Nee dus, dat maakt niets uit.

Een enkelvoudige zoekopdracht in een van de geindexeerde velden werd trouwens zonder merkbare vertraging uitgevoerd, d.w.z. DIRECT en ook browsen ging lekker vlot.

Zoeken in de portals ging ietsje langzamer maar toch vrijwel direct.

Persoonlijk zou ik alle tabellen (in principe) onderbrengen in het zelfde bestand, dat scheelt enorm veel scripts en capaciteitsproblemen zullen er met 8Tb niet snel zijn. Maar ik heb geen idee of veel tabellen (met veel Gb's) invloed hebben op de werksnelheid van FMP.

 

- hoofdtabel met 2 miljoen records

- 14 Gb!

- zoekvelden geindexeerd.

- zoekformulier met veel grafische ballast en 3 portals.

 

AMD Athlon 3000+ / 512 Mb / XP

[AvD]

Bedankt, Arnoud. Hiermee is dan ook meteen een duidelijk antwoord gegeven aan Ron7 hierboven.

[RON7]

Inderdaad,maar onder server 5 (met verschillende calculatievelden;sorteringen enz) is het toch een verschil?

[AvD]

Onder FM Server 5 (of 5.5) kan het toch niet anders! De mogelijkheid om je datatables in één enkele file onder te brengen is er pas vanaf FM7.

Het aantal calc fields, sort orders enzovoort maakt niets uit in dit opzicht. Vanaf FM7 maak je dus bij voorkeur gebruik van de mogelijkheden die er zijn.

[RON7]

Juist tuurlijk !!! Maar de vraag was of men inkoop,bestelling en fakturering in 1 al dan niet enkele bestanden moet onderbrengen.Tot 7 enkel mogelijk met verschillende databanken,maar nu verleidelijk om alles onder 1 bestand onder te brengen.Ik blijf voorstander om de belangrijke datainvoer bestanden (inkoopbon,bestelbon en faktuur bvb) gesplitst te houden.Verbeter als dit idee verkeerd is want ik moet verschillende zeer complexe databanken omzetten naar 7???

[AvD]

Voorkeur gaat naar single file (tenzij je data en interface nog eens wil scheiden).

Bij migratie van 6 naar 7 (en dat kan op vele manieren) kan je niet automatisch overgaan van multi file naar single file. Wil je single, dan moet je de zaak herschrijven (tenzij je geduld hebt tot de sinterklaasperiode...*).

---------

* Zie elders op dit forum...

[Arnoud]

De door mij uitgevoerde simpele 'test' geeft wellicht een verkeerd beeld.

Een uitgebreide test is beschikbaar onder de volgende link:

 

http://www.maclane.com/ubbthreads/showflat.php?Cat=0&Board=H0&Number=496925&page=0&fpart=2

 

Conclusie:

As things are now unless FileMaker does something serious on data management, the “Single File Format” for a large system is, in my opinion, a poor choice. It is not only slower, but if a client required a simple change to the file it would have to be delivered on an 18 wheeler.

[edc]

Misschien nog een ander argument om te scheiden is het volgende:

Ik heb een toepassing ontwikkeld voor het bijhouden van evaluaties op dagbasis van een 50-tal kinderen + nog een aantal andere zaken (allemaal op dagbasis). Het hoofdbestand bevat weinig of geen data met wel veel scripts en layouts. Er zijn wel een 10-tal relatiebestanden die dan al de data bevatten. Het is al gebeurd (sinds 7 jaar dat de toepassing in gebruik is) dat één van die relatiebestanden crasht. Het volstond dan om enkel de backup van het gecrashte bestand te terug te plaatsen en men kon weer verder. Bij de 9 andere bestanden is er dan geen data-verlies.

Wanneer men in fm7 alles in één bestand plaatst heeft men volgens mij meer kans op dataverlies bij een crash dan in voorgaande opzet.

Ik blijf dus voor dergelijke toepassingen met gesplitste bestanden werken.

[Rony Rabijns]

Wanneer men in fm7 alles in één bestand plaatst heeft men volgens mij meer kans op dataverlies bij een crash dan in voorgaande opzet.

Ik blijf dus voor dergelijke toepassingen met gesplitste bestanden werken.

 

Ik ben niet helemaal akkoord met EDC.

Een backup is een backup, of dat nu van 1 bestand is van of zevenendertig, dat maakt niet uit. Het voornaamste is dat er een backup is, en daar wringt meestal het schoentje bij de gebruikers.

Vaak is er gewoon geen backup en ja, inderdaad, dan ware het beter om niet alles in één bestand te stoppen.

Maar als we dàt als een argument gaan beschouwen om niet alles te bundelen ...

Ik (en klanten) werk(en) nu toch al meer dan een jaar met 7 en ben (zijn) nog geen crash tegengekomen in 7 (hout vasthouden), in 6 daarentegen ...

[RON7]

Sja blijft precies toch een discussie punt (edc tov avd).Maar een voorbeeldje dan:Ik heb een superette systeem lopen met zowel inkoop,retour en enkele magellan weeg kassas gelinkt via troi serial plugin.Elk heeft honderdduizenden records.Alles loopt op FM server en diverse rapportages zijn in gebruik.

Uuroverzichten,verkoperrapport,dagrapport,groeprapport,voorraad enz...

Dit in 1 enkel bestand zou al vlug over het miljoen records gaan,en indien dan bvb een periode rapport wordt opgevraagd dat berekend moet worden???

[AvD]

Voor zover ik weet is er van dat miljoen records niets te vrezen, omdat FileMaker 7 niet per file maar per table werkt. Bij queries gaat hij niet alle records doorzoeken, maar enkel die van de relevante table. En bovendien gebeurt dat nog eens index-sequentieel (dat is juist de grote kracht van FileMaker: push technology in plaats van pull technology). Daar werd in de tijd reclame mee gemaakt, maar de meesten schijnen dat inmiddels vergeten te zijn.

Natuurlijk, als we gaan spreken over grote Systemen (hoofdletter S gezien? ), dan moeten we wel een aantal zaken afwegen zonder daarbij fundamentalistisch te gaan doen...

[RON7]

Thx,ben nu begonnen met herschrijven van een systeem a la Stonewood ivm Haccp,productie en tracering (S of s ... toch een paar honderd databanken onder 6)Geef Avd gelijk betreffende onefile systeem.Maar had graag enkele opinies gehoord over de hoofdblokken.Het handelt zich om een centrale met verschillende filialen.

Ik ben van plan alle data betreffende klanten,leveranciers enz. in 1 databank "Databeheer" te stoppen.Vervolgens inkopen,Productie en verkopen van centrale en filialen elk onder "Inkoop","verkoop" en "Productie"

Rapportage en tracering loopt dan via queries tussen de 3 hoofdbestanden met naar schatting elk minimaal 30 tabellen en een groot aantal records.

Deze 3 samenvoegen zou resulteren in 1 grote blok van meer dan 100 tabellen;misschien makkelijker ivm scripting,maar de werking???

Iemand ervaring met dergelijke oplossing,want alles herschrijven is al een hele klus en nadien nog eens moeten veranderen zal zeker goed zijn voor mijn nachtrust

[AvD]

@Ron7

Er zijn snodaards op het internet - niet hier op Clarify - die al in de zak van Sinterklaas gekeken hebben en die nu al weten wat daar zoal inzit.

Dit betekent dat je nu om het even welke richting kunt kiezen, je kan het later* nog altijd om de andere boeg gooien

 

--------------------

* Wat "later" betekent weet ik echt niet. Je hoeft het dus niet te vragen.

[WJ]

Ik ben ook voorstander van de 1 file oplossing. Het scheelt zoveel werk op het gebied van beveiliging en scripting.

 

Je krijgt natuurlijk wel een grote hoeveelheid aan layouts en tabel occurences. Dit weegt volgens mij niet op tegen de vele voordelen.

 

Het grootste voordeel is dat je alles bij de hand hebt. De kracht van filemaker ligt in het feit dat je alles bij elkaar hebt. Database, Scripting en interface.

 

Een groot systeem opzetten in 1 file vraagt wel om logica. Vooral wat betreft naamgeving. Ik heb gemerkt dat als je goed nadenkt over de logica in naamgeving van layouts en tabellen in combinatie met het functionele gebruik scriptparameters je erg veel code generiek kan gebruiken en heel veel scripts direct voor nieuwe objecten kunnen worden gebruikt door de scriptparameter en logica in naamgeving.

 

Heel simpel voorbeeld go to layout name by calculation. geef als calculatie op scriptparameter. Dit enkele script kan je gebruiken voor al je navigatie als je je layouts logisch benoemd.

 

Verder is het een must om script te documenteren via de comment. Dit dwingt je na te denken over een script en zorgt ervoor dat het beheersbaar blijft tijdverlies is minimaal.

[Rony Rabijns]

Heel simpel voorbeeld go to layout name by calculation. geef als calculatie op scriptparameter. Dit enkele script kan je gebruiken voor al je navigatie als je je layouts logisch benoemd.

 

WJ, dit is een zeer goede toepassing van de scriptparameter.