Waar stopt het?

[Roger]

Sinds we van FileMaker 6 verlost zijn kunnen we in één enkele database vele tabellen aanmaken. Zo heb ik een applicatie aangelegd waarin ondergebracht zijn: producten, orders, voorraad, facturatie en pakbonnen. Maar waar houdt het op? Is het verstandig om een compleet ERP-systeem in één enkele database op te zetten? Ik sta nu op het punt om ook 'klanten' en 'contactpersonen' toe te voegen, maar iets zegt me dat ik er verstandig aan doe om dit in een separaat bestand onder te brengen omdat klant en contactgegevens niet echt veel met producten en orders te maken hebben. Van de andere kant, waarom zou je het niet doen? Misschien toch om het overzicht te bewaren en de relatiegrafiek een klein beetje overzichtelijk te houden?

 

Hoe doet u dat? Op basis waarvan besluit u om een extra tabel in een applicatie of juist een extra database aan te maken en waarom?

[JeanWM]

Voor die zaken bekijk ik het geheel buiten FileMaker.

Wat zijn de 'gevoelige gegevens'.

 

Ik bekijk het vanuit disaster management.

 

Natuurlijk maken we backups tijdens het ontwikkelen

 

Natuurlijk controleren we of de backups wel daadwerkelijk 'goed' zijn

 

Natuurlijk doen we ingrijpende veranderingen eerst op een backup en voeren de data daarna in....

 

Natuurlijk hebben we van al onze bestanden/toepassingen een blanco (up to date) masterfile...

 

Ik zou al degene die het niet doen niet te eten willen geven.

 

De toepassing wordt bekeken vanuit het standpunt van: wat kan er tijdelijk gemist worden in het proces ?

 

Die data zet ik altijd afzonderlijk en heeft mij al verschillende keren gered.

 

Ook de backups gebeuren niet alleen op FM niveau, maar ook op louter dataniveau.

Dat geeft de mogelijkheid om in het ergste geval de laatste blanco masterfile te nemen en de data backup te importeren.

 

Ik bekijk het vanuit het data-process-kritische standpunt.

 

Een voorbeeld ?

Is het erg indien ik de naam en adres van een student kwijtgeraak ? Neen, kan makkelijk teruggevonden worden.

 

Is het erg indien ik de betalingshistoriek kwijtgeraak ? Ja.

Facturatie is dus een afzonderlijk bestand.

 

Is het erg indien ik de gegegvens van een leverancier kwijtgeraak ?

Neen, kan makkelijk terug aangemaakt worden.

 

Is het erg indien ik de opvolging van aankopen en betalingen kwijtgeraak ?

Ja, boekhouding staat dus apart, klant en leveranciersgegevens staan in 1 bestand/multi-table.

 

1 peso con cinquanta centavos

[tackenco]

O jee, wat een lang verhaal.

Het komt er op neer dat je vindt dat bepaalde tabellen liever in een los bestand kunnen staan, indien er een bestand kappot gaat of zo?

 

Ik doe het zelf vaak op de volgende manier:

Ik maak een database die heet bijvoorbeeld data.

Hier zitten alle tabellen in die ik nodig heb, daarnaast maak ik een database die heet bijvoorbeeld interface, hier maak ik alle layouts en userinterface dingen. Ook de meeste (minstens 95%) functionaliteit zit in de interface.

Dit is heel handig als je updates moet doen, in de meeste gevallen hoef je alleen het interface bestandje te vervangen, de data blijft dan onveranderd, je hoeft dus niets te importeren. Mocht het databestand op de een of andere manier beschadigen en het is niet te herstellen dan vervang je het databestand met de laatse backup. Voor de meeste klanten heb ik server ingesteld op minimaal 2 backups per dag zodat je hoogstens een halve dag mist maar dat kan natuurlijk ook vaker.

 

Ik zou niet kunnen bedenken waarom dit niet genoeg is maar ik laat me graag overtuigen. Interessante discussie!

 

Groet,

Niels

[Gido_]

Wat bij mij oa opkomt:

 

- al naargelang je eventueel modules wil verkopen (al kan je haast evengoed reeds die functionaliteit inbouwen en later activeren)

- al naargelang hoe groot een bestand kan worden dat je eventueel nog wil kunnen mailen

- al naargelang de risico's en activiteit dat een bestand ondergaat

 

Zo heb ik bv een bestand met documenten/foto's, al dan niet hardcoded, dat bij een bestand met artikels hoort. Dit bestand is om de 2 laatste redenen voor mij uiteraard een apart bestand.

[PackD]

Ik volg volgende werkwijze:

- Data zeker trachten te scheiden van de interface en intelligentie

- Het geheel in logische modules onderverdelen (bv contactbeheer - projectbeheer - financieel - ...)

 

Eén grote file geeft mijns inziens te veel risico's en problemen op langere termijn.

[clarify9]

Puur theoretish is het zo dat het aantal mogelijke dataconnecties exponentieel toeneemt als de database steeds verder opgesplitst wordt.

 

Denk hierbij aan de discussies omtrent het wel/niet hebben van een micro-kernel!

[Roger]

Interessante reacties tot dusver! De rode draad ervan komt neer op het scheiden van data en interface met als voordelen, veiligheid voor de data en gemak bij updating.

 

Zijn er nog meer mensen die hierop willen reageren? Bent u het eens met deze werkwijze en/of kleven er ook nadelen aan?

[RON7]

Er zijn zeker nadelen,accounts in meerdere databanken,aparte related calculation fields moeten telkens met relaties in data worden aangemaakt,related valuelists,eventueel risico van vertraging ...enz

Handiger en meer overzicht wanneer men geen separatie toepast.

Corruptie kan trouwens zowel in interface als in data voorkomen, dus geen reden om separatie in te voeren.

En heu groot ? 5 miljoen records of zo...gebruik SQL table met FM

[SuperWimmie]

Het scheiden van data en de rest van de applicatie is voor mij totaal geen argument.... maar ik praat dus lekker voor mijzelf.

 

Want data zonder procedures is niet zo veel. Jawel, de data moet regelmatig gebackupped worden, want die verandert constant. Maar verder horen data en procedures bij elkaar, want nieuwe data met verouderde procedures werkt ook niet altijd.

Gezien de omvang van Filemaker bestanden qua procedures valt het allemaal nog wel mee.

 

Verder zet ik nogal wat dingen in aparte bestanden.

Waar ik naar kijk is de grootheid "module".

Oftewel, mijn Relatie kaartenbak zit in één Filemaker bestand. Daar zit heel veel functionaliteit in, zoals bedrijven / personen structuur, een branche-herkenningssstructuur, koppelingen met Word, Excel, telefoons, internet, email, routeplanners en agenda's etc.

 

Mijn Verkoopfacturatie zit in zijn geheel in een ander Filemaker bestand.

Die is ook weer heel luxe aangekleed, want deze bevat facturen, factuurregels, inkomende betalingen, aanmaningen, dagboekbeheer, BTW tabellen etc.

 

Waarbij ik beide modules zo zelfstandig mogelijk wil laten functioneren.

En zo heb ik nog wel een paar modules (stamgegevens, projecten, offertes-opdrachten, woningen, ritstaten).

 

Een compleet softwarepakket bestaat bij mij vrijwel altijd uit de modules Stamgegevens, Relaties en Verkoopfacturen. Wat daar tussen in zit, maakt het pakket specifiek voor de toepassing.

 

Een groot nadeel van één groot bestand is de onoverzichtelijkheid van alle structuren...

Zelf bouw ik heel veel luxe dingen in mijn systemen, dit zorgt voor nogal veel Table Occurrences, relaties en value lists. Probeer over 2 jaar dan zo'n systeem nog maar te doorzien, dan werkt het handiger als het een beetje apart wordt gehouden.

 

Maar ja, ik werk al zo'n 10 jaar met Filemaker en heb jarenlang gehobbiet om zover te komen.

De standaard opmerking "alles in één bestand" bekijk ik dan ook met grote argusogen. Zo zwart-wit zie ik dat niet.

Maar terug naar versie 6 dat alles aparte bestanden waren, nou nee. Daar verlang ik niet meer naar terug.

[clarify9]

Is dit een Model-View-Controller discussie?

 

http://en.wikipedia.org/wiki/Model-view-controller

 

Het splitsen van Model en View data is handig. Wijzigigingen in het datamodel of de userinterface kunnen dan snel gerealiseerd worden zonder dat de database niet meer werkt.

 

Om alles met elkaar te linken gebruik je dan de "controller" code.

 

 

.......... maar is dit wel mogelijk in Filemaker? Is het wel mogelijk een aparte tabel te maken die enkel het controller code bevat?

 

 

Kan iemand hier een demo bestandje van maken??

[Sternone]

 

 

.......... maar is dit wel mogelijk in Filemaker? Is het wel mogelijk een aparte tabel te maken die enkel het controller code bevat?

 

/quote]

 

Beste,

 

Ik ben beginnende FM Programmeur en mijn vraag komt ook op hetzelfde neer, kan ik verschillende FM Databases/Programma's 'mergen' door een Programma/Database boven te zetten ?

 

Of raden jullie beter aan om 1 algemene database te hebben, met verschillende presentatie layers ?

[Gido_]

Gewoon wat Googlen op "data separation model filemaker" en alles komt tot U FM heeft er ten tijde van FM7 ook een whitepaper over gemaakt, genaamd... "The Data Separation Model".

[clarify9]

@ Gido:

 

Het lukt mij niet om dit filemaker whitepaper te vinden.

 

Help?

 

......................................

 

Inmiddels tóch gevonden --> je verwees naar het bestand http://www.filemaker.com/downloads/pdf/techbrief_fm7_foundations.pdf is het niet?

 

Er bestaat overigens ook een FM 8.0 versie van deze uitleg: http://www.filemaker.com/downloads/pdf/techbrief_fm8_migrtn_found.pdf

 

 

Clarify9

[clarify9]

Wat ik me verder nog afvroeg of

 

Model, View, Controller hetzelfde is als Data, Interface, Business Logic?

Of dat dit toch twee verschillende zaken zijn??

[Gido_]

Inmiddels tóch gevonden --> je verwees naar het bestand http://www.filemaker.com/downloads/pdf/techbrief_fm7_foundations.pdf is het niet?

Wellicht, maar ik had dat hoofdstuk er vroeger eens uitgehaald en zelf benoemd, vandaar dat jij (en ikzelf) het niet meer kon vinden...

 

Hier staan ook 2 subscriber vids erover waarin Matt het zo streng mogelijk aanpakt:

www.filemakermagazine.com/videos/the-se ... rface.html

www.filemakermagazine.com/videos/the-se ... rface.html

($25 voor bijna 5 GB aan video's [en 2 dagen werk], dat kan je toch niet laten liggen hé? )

[clarify9]

Bedankt Gido voor de link.