Jump to content

Basics deel 1: structuur van een FileMaker database


Recommended Posts

Welke soorten velden bestaan er in FileMaker, en wat kunnen we er zoal in kwijt?

 

Overzichtje van de mogelijke velden in FM :

 

Getal :

Bevat numerieke gegevens. (let op : 01 is hier gelijk aan 1)

Tekst :

Bevat alfanumerieke gegevens. (let op : 01 is hier niet gelijk aan 1)

Datum :

Bevat datuminformatie dd/mm/jjjj (maar wordt intern eigenlijk opgeslagen als een numeriek volgnummer)

Tijd :

Bevat tijdinformatie hh:mm:ss (maar wordt intern eigenlijk opgeslagen als een numeriek volgnummer)

Tijdstempel :

Bevat tijd en datum informatie dd/mm/jjjj hh:mm:ss (handig voor triggers of registraties van gebeurtenissen)

Container :

Bevat multimedia (beeld, film, geluid) gegevens, ja zelfs volledige bestanden. De gegevens kunnen in Filemaker bewaard worden (nadelig voor de totale bestandsomvang van je Filemaker-betand), of als referentie (de originele bestanden staan ergens op je harde schijf)

 

Berekeningsveld :

Bevat de meest gangbare rekenkundige, analytische, geometrische, financiële, logische, ... functies. Het resultaat is altijd numeriek, tekst, tijd, datum, tijdstempel of container.

Met de Advanced versie van Filemaker kan je zelfs je eigen functies maken en gebruiken in berekeningsvelden. De gebruiker van jouw functie heeft dan weer geen nood aan de Advanced.

Resumévelden :

Een resuméveld is een veld dat het resultaat bevat van een resuméberekening van waarden in een groep van records. (totaal, gemiddelde, maximum, minimum, afwijking, telling, deviatie).

Ze worden gebruikt in rapporteringen (voorvertoning en afdruk).

Link to comment
  • Replies 57
  • Created
  • Last Reply

Top Posters In This Topic

Velden, in vele soorten en maten ...

 

Maar het is en blijft m.i. nog steeds het moeilijkste om voorafgaandelijk de beste planning te maken, kortweg, hoeveel en welke velden heb ik nodig. Is het bvb interessant om zo veel mogelijk data op te splitsen, bvb. een adres verdelen in een straat, nummer, bus, postcode, gemeente, land, enz... -veld?

 

In hoeverre wordt de snelheid van het databasesysteem beinvloed door een 'overschot' aan (nutteloze) velden? Calculatie- of rekenvelden kunnen een nefaste invloed hebben op de snelheid, dus vooral met dit type van veld dienen we enigszins voorzichtig om te gaan. Waarschijnlijk zal het ook weer hier zijn dat matiging de mooiste kunstwerken voortbrengt.

 

Weerom kijk ik uit naar de talrijke antwoorden ...

 

Groeten vanuit een grijs en nat Broekzele,

 

Stardust

Link to comment
In hoeverre wordt de snelheid van het databasesysteem beinvloed door een 'overschot' aan (nutteloze) velden? Calculatie- of rekenvelden kunnen een nefaste invloed hebben op de snelheid, dus vooral met dit type van veld dienen we enigszins voorzichtig om te gaan.

 

Antwoord op vraag 1 :

Snelheid wordt niet zozeer bepaald door de hoeveelheid aan nutteloze velden. Maar ze vermijden is natuurlijk beter.

 

Antwoord op opmerking 2 :

Calculatievelden zijn nefast voor de snelheid wanneer ze niet geïndexeerd zijn.

Link to comment

Of wanneer je een 'te berekenen' veld gebruikt in een 'te berekenen' berekening.

 

Het is soms beter die berekening in je berekening te maken.

 

Voor de details is het beter zo 'enkelvoudig' mogelijk te werken.

Dus bv. een adres inderdaad op te splitsen in elk onderdeel ervan, 'saucisoneren' als het ware.

 

Indien je voor 100 gr salami gaat (is geen 'vuile vriend', maar een boterhambelegsel.. :roll: ), kun je dit beter gebruiken indien het in schijfjes gesneden is, dan 1 blok van 100 gr.

 

Hetzelfde gaat voor gegevens over een item dat je in velden moet stoppen.

 

Vandaar het eerst op papier uitwerken van een toepassing vóór je begint rond te klikken.

Link to comment

Jean schreef:

Dat is de reden waarom ik de 'behangpapierfase' heb ingevoerd....

 

Jean, Ik probeer me dat hier even voor te stellen ... maar ik heb het er nogal moeilijk mee. Al de layouts maken vooraleer je aan de velden en zo begint, lijkt me niet vanzelfsprekend.

 

Misj schreef:

'k ben dus nu wat blij dat ik twee maand geleden op deze site terchtkwam.

Ik hoop dat er nog veel mensen in jouw spoor zullen volgen Misj !

 

Nu moeten we nog enkel al deze berichten gaan samenvatten en in boekvorm uitgeven. Dat zou een bekroning zijn voor het forum en volgens mijn bescheiden mening wordt dit de ultieme handleiding voor FM.

 

Nog slechts enkele onderwerpjes te gaan dus :wink:

 

Danny (die altijd blauwe lettertjes gebruikt) 8)

Link to comment

De door Jean genoemde "behangpapierfase" is eigenlijk de essentie van de ontwikkeling van een databeesje...

 

Eigenlijk moet je beginnen met: wat wil ik eruit halen? welke overzichten of rapportages moeten door de database worden gemaakt en op welk detailniveau? Pas als je weet wat je er uit wilt halen kun je ook beredeneren wat je erin moet stoppen...

Link to comment

Beste Burggraaf,

 

Dat is inderdaad zo ... de planning daar begint het ...

 

Maar, men zou ook in feite een beetje Madame Blanche moeten kunnen spelen. Hoe vaak gebeurt het niet dat er aangepast en gewijzigd moet worden. Vaak heeft men een geweldig draaiend bestand of systeem om na allerlei latere aanpassingen te eindigen met een 'draak' van een bestand waar je de angst om het hart slaat bij het idee dat je daar nog iets aan moet veranderen. Geloof me, ik spreek (helaas) uit ervaring.

 

Daarom dat hetgeen wat Jean de 'behangfase' placht te noemen me wel interessant lijkt, alleen kan ik me het moeilijk voor de geest halen. Beginnen met de layouts lijkt wel een frisse benadering maar ik kan het me niet voor de geest halen, tenzij dit op de tekentafel is.

 

Desondanks ben ik nieuwsgierig, ik zou zo graag een compleet systeem ontwikkelen dat 'af' is, het woord perfect durf ik niet te gebruiken daar ik terdege besef dat perfectie een niet bestaande toestand is.

 

Meestal begin ik met een groot (A3-formaat) leeg blad en teken daar heel rudimentair mijn project uit. Ik begin met de verschillende tabellen, de velden, de relaties en de layout laat ik meestal voor het laatste.

 

Ondertussen voel ik me wel gevangen in het Pre FM7 denken, ik heb het verdomd moeilijk om me in de FM7/8 denkwereld te begeven. Waarschijnlijk is het feit dat ik nog dagelijks noodgedwongen aan het 'knoeien' ben met Filemaker 6 hier niet vreemd aan. Ik kan me nog steeds niet van de indruk ontdoen dat het verschil tussen 6 en 7 enorm is. Helaas kan ik niet zoveel tijd besteden aan Filemaker de laatste maanden en mijn leeftijd maakt dat ik ook niet meer zo flexibel ben in mijn denkwereld.

 

Het is mijn overtuiging dat het 'grote' plan vooral in je hoofd begint, maar helaas zijn we niet allemaal goede analisten, laat staan ontwikkelaars waardoor het plan na enige tijd al lang niet meer conform is en we in ons onderwerp afwijken van dit ideaal.

 

 

Danny

Link to comment

Ik weet niet waar ik ga eindigen met dit....

 

Geen nood Danny, dit kun je zowel in 7/8 als in alle andere versies gebruiken, je moet het enkel up-to-date houden.

Je zult dus nooit de schrik hebben dat het monster je in de lagere regionen gaat bijten....

 

 

Het ‘lijkt’ niet vanzelfsprekend, eerst met de layouts te beginnen, maar het is het wel.

 

Laten we even de ‘veronderstelling’ toer opgaan.

Je wil een toepassing maken om al het personeel op te volgen, aankomst/vertrek tijd registreren, de uren en uitbetalingen berekenen.

 

Je begint met ‘in gedachte’ door je toepassing te wandelen en verschillende ‘acties’ te bedenken.

 

Ik open mijn toepassing (openingsscherm = layout 1.).

Vandaar ga ik naar een menu waar alle mogelijke items instaan (menuscherm = layout. 2.)

Personeelgegevens (layout. 3.), tijdsregistratie (layout.4.), overzicht alle personeel (layout.5.), detailoverzicht personeelslid (layout.6.), detailoverzicht uren personeelslid (layout.7.), samenstellig loonstaat (layout.8.),afprinten loonstaat (layout.9.), bepaalde gegevens niet zichtbaar voor ieder willekeurig gebruiker (layout.10.), zoekscherm (layout – laat een gebruiker nooit een invulscherm gebruiken als zoekscherm.11.), basisloongegevens (layout.12.). Natuurlijk heb je een developerlayout (layout.13. ) en een All fields (layout. 14. )

Zie je, nog geen klik in FileMaker en al 14 layouts…..en je kunt er waarschijnlijk nog enkele bedenken....

 

En zo ga je verder. Voor iedere layout neem je een afzonderlijk blad. Door deze nu in een bepaalde volgorde te zetten, bv. Per table/file, verkrijg je een beeld hoe je door je toepassing gaat navigeren. Je duidt dus op iedere layout/blad aan waar je naartoe wil (naar welke layout) en ook vanwaar je komt, van welk blad/layout/table/file. Noteer ook waarom je naar een layout wil, welke gegevens of wat te doen. Dit geeft je een totaal beeld van de navigatie en krijg je een zicht welke knoppen waar je dient te zetten.

 

Knoppen = scripts, je verkrijgt al een lijst van navigatiescripts.

Tegelijkertijd noteer je ook voor iedere layout (op ieder blad) hoe het zicht moet zijn.

Invul (browse), list, table, search, enz.

Hier ga je ook vinden of het een ‘echt’ zoekscherm moet zijn, of dat je met het invullen van globalen een zoekactie wilt/kunt doen.

 

Als dit achter de rug is (maar het is nooit echt 'af') heb je automatisch een vrij goed gedocumenteerd geheel, zonder veel moeite, maar met heel wat informatie. Een klare kijk.

 

Nu gaan we naar de behangpapierfase.

 

Om een totaal overzicht te hebben van je toepassing kun je natuurlijk alles uittekenen op A4tjes of A3 of zelfs A1 of A0 en die aan mekaar plakken. Het blijft altijd plak en knipwerk.

 

Behangpapier heeft van nature uit 2 kanten, een voor en achterkant (wel...eigenlijk 4 kanten, mar de zijkanten zijn wat smallekes uitgevallen). De voorkant wordt gebruikt om naar te kijken, maar dat gaat snel vervelen, de achterkant gebruiken we voor onze toepassing op uit te tekenen. Gemiddeld is het 80 cm breed en enkele meters lang. Je kunt er vrij goedkoop aan geraken in ‘de detailhandel’, waar ze doorgaans ‘overschotten’ hebben. Gebruik natuurlijk enkel ‘vlak’ papier, geen relief.

Hier kun je alles op uittekenen wat je nodig hebt.

 

Met je layoutbundel begin je te bepalen welke velden je op welke layout wil/moet hebben. Breng de naam van de layout over op het behangpapier en maak de lijst van velden. Maak een onderscheid tussen zichtbaar en niet zichtbaar.

 

Hier kun je volledig uittekenen (over meters), in verschillende kleuren, wat de relaties zijn tussen de velden en de layouts. Je zult steeds een totaal overzicht houden over de volledige toepassing. Je kunt er met verschillende tegelijk aan werken ('rond de tafel' gesprekken), je opent enkel het deel dat je nodig hebt of je rolt het geheel volledig open.

 

Je kunt zoveel wijzigingen aanbrengen als nodig, gommeke gebruiken,…

Zo krijg je een zicht van wat gerelateerd is met wat, en waarom. Geef een naam aan iedere relatie, bepaal je sleutelvelden.

 

Op die manier zie je welke velden waar zijn, of ze al bestaan, of ze wel op de meest aangewezen plaats/layout/table staan

 

Op je layoutblad teken je de velden die zichtbaar moeten zijn, hiermee verkrijg je een beeld van het ‘layout zicht’, hoe dat eruit ziet.

Of je een portaal nodig hebt. Portaal = relatie = gerelateerde sleutelvelden = controle op heb ik die en waar zijn ze....

 

Het geeft je ook de mogelijkheid om na te gaan of de nodige velden wel op een layout staan voor de toegepaste techniek.

Veronderstel dat je een copy/paste script hebt. Je weet dat de gebruikte velden op een layout zichtbaar moeten zijn. Hiermee kun je de controle doen, en heb je ook de keuze: is het beter de velden ergens zichtbaar te maken op de plaats waar ik ben, of dien ik een navigatie in te bouwen naar een layout waar ze al zijn (all fields layout).

 

Vandaar mijn stelling: begin met de layouts en gebruik behangpapier.

Je rolt de toepassing op en kunt die bewaren zoals architecten hun plans bewaren.

Keurig, netjes, overzichtelijk, altijd bij de hand, gereed voor wijzigingen, geeft je altijd de ware toestand van je toepassing en je hebt een gedocumenteerd geheel. En dat alles zonder al te veel moeite.

Je dient wel elke verandering die je wil doen ook te documenteren op je overzicht, een layout bij = blad bij = navigatie bij enz.

 

Het is de enige manier om altijd een juiste versie te hebben. Op een afzonderlijk blad hou je de veranderingen bij met datum, op het overzicht kun je onmiddellijk zien welke invloed een verandering heeft/kan hebben...

 

Dat was een heel korte inleiding. Indien vragen en bedenkingen......

Link to comment

Buiten het letterlijk gebruik van behangpapier... (krijg ik hier echt ruzie thuis :lol: ) Inderdaad...

 

Het gewoon ergens beginnen is overigens geen onbekende eigenschap van Filemaker ontwikkelaars (ja, ook ik maak me er wel 'ns schuldig aan... :oops: ) Zo lang het een éénvoudig kleine database is, is dat ook niet zo'n probleem. Het riscico is dan echter dat er iedere keer wat bij wordt geplakt en uiteindelijk totaal onoverzichtelijk.

 

Wat je zult merken als je het doet is dat je van te voren weet waar je rekening mee moet houden en er niet halverwege achterkomt dat je beter toch een aantal zaken anders had kunnen doen....

Link to comment

Dit is de thread met de meest off topic praat die ik ooit gezien heb... :D:lol::roll:

Plezierig is het genoeg Jean, ik lig echt dubbel van jouw behangpapier benadering...

 

Maar er wordt hier over layouts gepraat, terwijl we dit eigenlijk helemaal nog niet besproken hebben. We zitten eigenlijk nog te bekijken wat velden zijn - zeer goed en compleet antwoord van Rony, maar dat zijn we gewoon - en zelfs daar zijn we nog niet helemaal mee klaar.

 

Ik voel me nu een echte schoolmeester, maar ... er moet een beetje orde in de de FileMaker klas blijven. Dus even bij de les blijven - stelletje uitgelaten... nee laat maar :wink:

 

Nu we tot op een zeker niveau weten wat velden zijn, gaan we verder met de structuur van een FileMaker bestand.

 

We hebben dus een bestand met tabellen, en die tabellen organiseren gegevens in velden, en naargelang de soort informatie, zit die weer in verschillende soorten velden.

Velden van een tabel zijn op hun beurt weer georganiseerd in records, als het ware de fiches van de fichebak of de rolodex.

 

Mooi. Stapje verder nu.

 

Wat zijn FileMaker layouts, en waarvoor dienen ze?

 

En probeer het een beetje simpel te houden, guys. Het is echt heel moeilijk om sommige basisbegrippen op een eenvoudige manier uit te leggen, ik ben zeker dat jullie hier een erezaak van willen maken.

 

[bTW, ik denk dat we goed bezig zijn, want deze thread trekt een record aantal views op een paar dagen tijd]

Link to comment
Dit is de thread met de meest off topic praat die ik ooit gezien heb... :D:lol::roll:

Plezierig is het genoeg Jean, ik lig echt dubbel van jouw behangpapier benadering...

 

 

Af en toe moeten we eens een zijsprongetje maken zodat iedereen weer goed kan volgen....en Danny had even een vraagje....

 

En vergis je niet....

Die methode gebruik ik écht (échte rollen) in mijn cursus en het blijkt een plezierig onderdeel te zijn dat navolging heeft. In het begin werd wel wat raar gekeken, maar nu niet meer. In tegendeel. Dat is ook het moment waarop de discussies beginnen over wat wat is, waar best gezet wordt, hoe best gedaan wordt.

Échte 'rond de tafel' gesprekken....

 

En van de reeds bestaande wordt ook dikwijls gebruik gemaakt om bepaalde technieken na te gaan of om als voorbeeld te gebruiken.

 

Een layout is een mogelijkheid om elementen in een 'aangenaam voor het oog en gebruik' compositie aan de gebruiker te tonen
Link to comment

Een layout is een onderdeel van een Filemaker-applicatie dat gebruikt wordt om gegevens te visualiseren (bladeren, voorvertoning en afdrukken) of om gegevens te zoeken (zoek-modus).

Een layout bestaat uit een verzameling van objecten. (rechthoeken, cirkels, tekst, grafische elementen, velden)

De velden bevatten gegevens uit de tabel waaraan de layout gekoppeld werd, of gegevens uit tabellen die gerelateerd zijn met (in verbinding staan met, je moet de knoopjes kunnen volgen) de tabel waaraan de layout gekoppeld werd.

Layouts bevatten verschillende delen. Zo is er een titelhoofd dat bovenaan de eerste pagina verschijnt bij een afdruk van die layout; een titel-gedeelte dat bovenaan iedere pagina staat van een afgedrukte layout; een résumé-gedeelte dat informatie bevat die voorafgaat aan gesorteerde data; een hoofdgedeelte waarin je de eigenlijke gegevens uit de records toont; en dan ook nog de tegenhangers van de titeldelen, de zgn. voetgedeeltes, die vanzelfsprekend onderaan een afdruk verschijnen.

Link to comment

Krijg ik nu niet het gevoel dat meester Peter zijn gezag aan het verliezen is :lol: Alleszins, off topic of niet, de benadering van Jean is op z'n minst heel origineel en zijn argumentatie houdt (na goede gewoonte trouwens) wel steek. Dit topic is op z'n minst zodanig leuk dat ik niet kan laten om tussen m'n studie door af en toe eens te komen piepen. Als dit zo verder gaat moet er toch een nieuwe groep voor deze discussie worden opgezet (Peter :?: ), het zou zonde zijn mocht dit allemaal verloren raken in de massa.

 

Zoals gewoonlijk zijn de bijdragen van Rony zakelijk, functioneel en 'to the point', ik zou ze gebruiken als de inleiding van elk hoofdstuk :wink:

 

Ik moet weldra, wanneer de tijd dat toelaat, eens beginnen aan een volgende versie van ons systeem op het werk maar wacht af tot we eindelijk over versie 8 of moet ik nu al hopen op versie 8.5, beschikken. Na de vruchtbare confituursessie besef ik nog meer dan ooit tevoren m'n eigen nietigheid tussen al dat talent en durf ik nog amper te beginnen vooraleer we deze 'discussie' tot een vruchtbaar einde gebracht hebben.

 

Alleszins, de behangfase van Jean ga ik toch gebruiken. Het geeft inderdaad al een goed inzicht in het project dat men wenst te verwezenlijken en vooral het brengt al een aantal problemen naar voren waar men vroeg of laat met te kampen zal krijgen.

 

Om toch een beetje mijn reputatie van 'moedwilligaard' bij te treden (ik ben Antwerpenaar voor iets), durf ik zelfs in te gaan tegen Peter. Reeds de 'behangpapier fase' toepassend, kom ik tot de ontdekking dat de eerste, hier weliswaar afgesloten, analysefase terug aan bod komt.

 

Maakte men voorheen met de fossiele FM versies allemaal losse bestanden die eventueel via een menu gekoppeld werden, kunnen nu al die tabellen samen in één bestand gebracht worden. Stel dat men al de werkzaamheden op kantoor via Filemaker afwerkt en dat al de werknemers polyvalent zijn - zoals heel toevallig :wink: dit bij mij het geval is - gaat men dan opteren om al de tabellen in één bestand te maken wat tot een totaal van een 50 tal tabellen, ca 2500 velden en een kleine 100.000 records gaat leiden, of maakt men toch beter gebruik van verchillende bestanden. Met verschillende bestanden schuilt het gevaar weer om de hoek aangaande het vollopen van de systeembronnen waar Jean me nog niet zolang geleden op gewezen heeft en waar ik in de praktijk regelmatig met af te rekenen heb. Anderzijds vraag ik me af of zo één monsterbestand nog wel werkzaam blijft.

 

Allemaal vragen die me terug voor de geest komen na het overdenken van de wallpaper fase van Jean (en te zeggen dat ik liever schilder) :? Net toen ik dacht, we gaan een stap verder, kom ik voor mezelf tot de conclusie om even een stapje terug te gaan. Waarschijnlijk is dit positief, beter nu in de beginfase dan later wanneer het systeem bijna op poten staat, of niet?

 

Een database is dus niet alleen een verzameling van zogenaamde handige trucs, het is vooral een kwestie van planning en organisatie.

 

Oef wat een reply ... hopelijk heb ik nu niemand in slaap gewiegd :oops:

 

Anders slaap lekker en tot morgen ...

 

Danny

Link to comment

Heren, ik dank jullie voor jullie bijdrage. Hopelijk hebben we niemand nog meer in de verwarring gestort.

 

Bijgevoegde screendump komt uit Script Debugger 4 voor Mac, een AppleScript editor "on steroids", onmisbaar voor het zwaardere AppleScript werk.

Heel veel van wat we geleerd hebben deze week over de FileMaker structuur kom hier in terug.

 

Interessant is zeker dat die dingen allemaal met elkaar verbonden zijn, en altijd in een bepaalde context moeten gezien worden.

Voor de absolute beginnner: trek je niets aan van "repetition", dat is 1 van de eigenschappen van een veld, en gaan we later aanpakken.

Merk op dat men "cell" gebruikt om een een veld van een record aan te duiden, terwijl men met "field" het eerder heeft over de "kolom" van onze 2-dimensionele tabelstructuur.

 

Een laatste belangrijk structureel element in FileMaker is het script. Dus als laatste vraag van dit eerste hoofdstuk:

 

Wat is een FileMaker script, en waarvoor gebruik je het?

 

Om niet te veel topics in 1 thread te behandelen, zou ik het hier bij willen houden qua vraagstellingen, en stel voor dat iemand met een deel 2 begint, dat andere algemene zaken belicht of dieper ingaat op de dingen die we hier algemeen aangetoetst hebben. Onderwerp zelf te kiezen.

5a758dc31357a_ScriptDebuggerScreenSnapz001.png.d8fcced73e8a4fb8c378235bc64488ea.png

Link to comment
Wat is een FileMaker script, en waarvoor gebruik je het?

Een script is in zijn pure vorm een verzameling van commando's, te vergelijken met een macro of waarom niet, een bat-bestand onder DOS (cmd onder Windows).

 

Met een script kan je een hele reeks handelingen achter elkaar laten uitvoeren.

 

De scripts kunnen zodanig samengesteld worden dat het wel op een (intern) programma begint te lijken.

 

En nu is het aan de specialisten :roll:

Link to comment

Danny,

 

misschien start je best zelf met een vraag.

 

Mijn ervaring is dat 5 beginnende (of zelfs verder dan beginnende) 5 verschillende problemen/richtingen uit willen.

 

Het forum spitst zich meer toe op kleine individuele problemen en bijna nooit wordt het meer algemene beeld van een database als probleem behandeld.

Terwijl de kleine problemen meestal hun oorsprong vinden in een mis (of helemaal niet) interpretatie van basisregels.

Denk maar aan de normalisatie regels (onze vriend Codd komt weer kijken)....

Link to comment

Hier sta ik dan met de mond vol tanden ...

Ontwerp - Codd - Normaliisren en dus relaties voorzien en definiëren!

 

Het lijkt allemaal zo logisch en vanzelfsprekend tot je er effectief aan begint. Vooral wanneer men gewoon was om met de oudere FM versies een database op te zetten, is dit een hele ommekeer.

 

Het grote verschil tussen tussen pre en post 7 steekt nu de kop op...

 

Relaties ... eerst waren ze niet, toen kwam versie 3 en we waren gerelateerd ... tot versie 7 ons verblijdde met de mogelijkheid om relaties te definiëren zoals de 'groten'. Een enorme sprong voorwaarts of misschien de grote rem, wie zal het zeggen. Alleszins we moeten verder en zijn we dus verplicht om ons aan te passen en bij te scholen. Hoewel ik me zeker niet als een beginneling willen klasseren voel ik me nu vanaf v7 vrij hulpeloos. Al hetgeen wat ik kende, komt nu enigszins op de helling te staan. Plotseling zijn de parallellen met bvb MS Acces heel duidelijk desondanks ik het gevoel heb dat met FM Pro nog steeds veel meer mogelijk is.

 

Relaties leggen, het succes van de database en de ramp voor de jongens en meisjes die niet tot de WZSG behoren ... Wanneer je er over leest en ook over nadenkt, lijkt het wel logisch, om het in de praktijk toe te passen is het een 'ander paar mouwen'.

 

Ik herinner me ondertussen lang geleden, het was nog FM Pro v2.1, een aanrader van een oude Mac gebruiker die me overtuigd had om kennis te maken met Filemaker Pro, nu (toen) ook beschikbaar voor DOS pc's (Windows kwam nog maar pas om de hoek kijken). Al snel had ik m'n eerste database klaar, een klassieker, het adressenbestand. De Posterijen hadden een database in dbf formaat ter beschikking van de Belgische postcodes en deze was vrij eenvoudig te importeren en om te zetten naar Filemaker Pro. Dankzij de lookup functie van Filemaker kon je bij de postcode die je getypt had, automatisch de bijpassende gemeente laten aanvullen in het 'woonplaats' veld. Wie had er nu relaties nodig ? Het klinkt waarschijnlijk heel infantiel maar ik verzeker jullie, er ging een wereld voor me open! Jaren lang heb ik allerlei databases gemaakt en gebruikt. Een volgende stap was om alles te combineren en het kon niet op ... samengebruik van de databases in het netwerk. Het bleef maar groeien tot het op de duur één groot systeem werd. Versie 3 kwam er aan en schoorvoetend maakten we eenvoudige relaties, versie 4, 5, 5.5 en 6 volden elkaar snel op en steeds pasten we onze bestanden aan aan de mogelijkheden van de nieuwste versies. Af en toe begonnen we ook een aantal databases terug op te bouwen vanaf 'scratch', maar hoe we ook knoeiden de boel bleef draaien. Tot versie 6, ons systeem was zodanig uitgegroeid en ook de werknemers waren verdubbeld. Van 2 werknemrs waren we tot 4 à 5 werknemers gegroeid en ook ons databasesyssteem was uitgegroeid. Alles draaide via Filemaker, MS Word en (helaas) Word Perfect werden nog amper gebruikt. E-mails werden verzonden vanuit Filemaker, gewoon door op het knopje te drukken.

 

Nu bij versie 8 (weldra 8.5 ??) belandt voel ik het duidelijk aan dat we helemaal vanaf nul terug moeten beginnen. Op zich een nobel doel, alles netjes en volledig volgens de regels der kunst van het databaseontwerp. Bij wijze van test ben ik er onmiddellijk aan begonnen, niet 1 maal, niet 3 maal maar ondertussen al vele malen en telkens weer opnieuw. Ofwel copieer ik alles uit de vorige versie teneinde tijd te winnen of anders raakt het project niet op dreef.

 

Alleszins is het duidelijk zoals ik reeds verschilelnde keren hiervoor beschreef en veel anderen met mij, het ontwerp is van levensbelang. Codd en de link in mijn topic hiervoor kan ons al een heel eind op weg helpen, misschien is de truc met de post-it's nog zo slecht niet :oops:

 

Vooraleer ik aan scripts begin te denken, moet ik een ontwerp uitkienen waarbij in de definitieve vorm zo weinig mogelijk ingevoerd dient te worden en waarbij de inhoud gewaarborgd is en blijft. Nog maar enige dagen geleden zag ik de manier van Jean bijna als zaligmakend (de behangpapierfase) maar daar begin ik ondertussen terug van te komen. De papier, knip en plakmethode in de ontwerpfase is de belangrijkste. Zodra het ontwerp op papier staat kan je beginnen met de tabellen te bouwen en in tweede fase de relaties te leggen. Dit alles met steeds in het achterhoofd, welke data wil ik verzamelen, wat wens ik met deze data te doen en welke taken wil ik op basis van deze data uitvoeren wat ons tot de layout fase brengt en uiteindelijk tot de script fase waar de knopjes voor de layouts gecreëerd worden en vervolgens de bijzondere taken samengesteld worden.

 

Klinkt allemaal mooi, maar waarom moet ik nu steeds herbeginnen?? :roll:

 

Ik denk dat we inderdaad tot een voorlopig einde gekomen zijn. Het enige nog meer uitgediept moet worden zijn volgens mij de relaties, al de rest staat inderdaad al reeds in diverse vorm over het ganse forum verspreid. Wanneer het ontwerp klaar is en de relaties gelegd zijn, is het in feite nog slechts een leuke en creatieve bezigheid :o

Link to comment
Dat was een heel korte inleiding.......

 

Ik ben niet verder in detail gegaan, maar het werkt echt.

 

We gebruiken ook Post-It om delen op te bouwen, we gebruiken mini wasspelden om grotere papieren ergens vast te maken, zelfs visdraad om tijdelijke verbindingen aan te geven.

 

Database opbouw moet in de eerste plaats plezant zijn, je moet fun hebben, je verbeelding laten werken en tegelijkertijd beproefde regels in acht houden.

 

Het moet niet mooi en perfect zijn, het moet een instrument, een tool zijn, dat je creatief gaat gebruiken.

 

Het nadeel voor jou misschien Danny is dat je nog nooit -live- een opbouw hebt meegemaakt.

Waarschijnlijk daarom dat je steeds opnieuw moet beginnen. Tot je een methode vindt die voor jouw werkt.

Ondertussen ken je verschillende methodes die NIET werken, dus blijft het leerrijk.

 

 

 

Ofwel copieer ik alles uit de vorige versie teneinde tijd te winnen of anders raakt het project niet op dreef.

 

Daar zit het probleem. Er wordt te weinig tijd uitgetrokken om het van in het begin goed te doen, te documenteren. Het gaat al snel vervelen omdat er geen onmiddellijk 'resultaat' schijnt te komen en dan grijpt men in FM al snel naar muis en toetsenbord en begint rond te klikken en velden aan te maken, en lijntjes te trekken en dan loopt het geheel krijsend vast.

 

Een portaal geeft op alle regels dezelfde data, een summary geeft een verkeerd totaal (en als je dat op tijd ontdekt mag je lachen), een rapportopbouw lukt van geen kanten en nog van dat fraais....

 

Dan maar op een forum gaan, en doorgaans begint het antwoord met 'maak een veld aan.....', of maak een TO aan, en we zijn terug aan de startlijn.

 

Men had het kúnnen zien, kúnnen weten, kúnnen aanmaken, kúnnen uitvissen.

En meestal is de opbouwfase zo ver, is er al zoveel tijd en moeite in gaan zitten dat het de moeite niet meer loont om 'te herbeginnen'.

Dan krijg je krammikerige databases, waar op termijn een 'vak ontwikkelaar' duidelijkheid in moet gaan scheppen.

En dat kost op termijn meer dan zich even de moeite te getroosten om op een degelijke manier aan de opbouw te beginnen.

 

Doe zo voort, ik verdien mijn plaatselijke boterham daarmee en ook nog iets om er tussen te leggen.

 

Jean groet allen die zijn en hierna wezen zullen en stapt van zijn zeepkist.

Link to comment
Al wachtend, blijf ik op m'n honger zitten :wink:
Ik denk dat je het redelijk goed hebt gesmurft, Database Smurf.

 

"ScriptMaker™" wordt onze vriend in de wandeling genoemd. Oorspronkelijk heette hij gewoon "Scripts", alhoewel, dat gaf ook weinig blijk van bescheidenheid. Scripts zag er oorspronkelijk zó uit:

scripts.png

Hij maakte een soort van snapshot van waar je was, hoe je pagina-instelling was, je gebruikte zoekopdracht, je huidige sorteervolgorde, enz.

 

Vanaf FileMaker Pro 2 begon hij door te krijgen dat hij wat te veel streken had, en veranderde z'n naam. Hij begon er toen zó uit te zien:

scripts2.png

Nu kon je al kleine programmaatjes maken. We ware toen allemaal kopieer-en-plak-programmeurs, want dat was de manier van werken.

 

Mettertijd werd ScriptMaker steeds gesofistikeerder. Je kon if-then constructies maken, loopjes maken, en vanaf FileMaker 8 heb je ook variabelen ter beschikking.

ScriptMaker is niet echt een programmeertaal. Het is een point-en-click systeem waar je instructies achter elkaar mee kan zetten. Point-en-click omdat je dan zo weinig mogelijk kan fout doen.

 

ScriptMaker routines kan je oproepen vanuit het menu, maar ook aan layout-objecten hangen (jeweetwel: knopjes), op die manier is een FileMaker bestand tegelijktertijd in staat om een kaartenbak te zijn, én een programma.

Link to comment

Ik knijp er even tussenuit, kwestie van aan een kleurtje te raken, een mens raakt zo snel uitgekeken op zwart-wit ... maar laat aub dit topic verder groeien, ik kijk al rijkhalzend uit naar het vervolg.

 

Prettige vakantie aan iedereen die er van kan en wil genieten.

Link to comment
  • 1 year later...

Met plezier heb ik deel 1 gelezen (sommige paragrafen gecopy-pastet om later uit te printen en op 't gemak te herlezen) maar ik weet nu al dat ik niet dommer ben geworden (integendeel!)

 

Mij reeds op voorhand verheugend op het lezen van deel 2 begon ik een klikqueeste. Alas! Bitterzoete ontgoocheling! Geen vervolg :cry: gevonden!

Waar zijn de andere delen?

En waarom heeft dit deel geen sticky gekregen?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...