global database

[pjotter]

In mijn ledendatabase zitten nog al veel velden (te veel naar mijn idee) totaal 100 stuks. Dat is gewoon te veel als er veel leden zijn want dan wordt de database gewoon te traag. In de ledendatabase zitten een 25 global velden. Is het verstandig deze in een aparte database te zetten? De database is zo groot omdat er enorm veel mogelijkheden zijn bij de prijs berekeningen.

(Voor dat DJ begint met normaliseren ik zit er zelf ook aan te denken. en zit te denken aan een aparte database voor prijs berekening. maar dat is een volgende stap)

[AvD]

In mijn ledendatabase zitten nog al veel velden (te veel naar mijn idee) totaal 100 stuks. Dat is gewoon te veel als er veel leden zijn want dan wordt de database gewoon te traag.

 

Sorry Pjotter, maar ik ga het cru zeggen: dit is gewoon nonsens. Honderd velden is teveel, zeg je. We zouden eens moeten vragen aan de forumleden welke databanken zij hebben.

Wat wel zo is, dat is dat je bij interdependente calculaties en complexe lay-outs waar veel van die velden getoond (moeten) worden, de nodige tijd uitgetrokken wordt voor die calculaties. Maar dan zit je al heel wat verder dan hetgeen je voor jouw geval beschrijft.

Ik denk dat je de database engine van FileMaker flink onderschat en geloof zelfs dat je geen idee hebt wat FileMaker onder de databanken zo uniek maakt(e): ooit gehoord van push technology versus pull technology?

Doe dus maar gerust verder: je zit nog ver van de actuele recordhouder met tientallen miljoenen records en honderden velden (een Amerikaanse telefoonmaatschappij).

[Theo2]

Er is niets op tegen om globale velden in een algemeen bestand te zetten. Er dient een vaste relatie te komen van al jouw databases naar dit bestand waarin slechts 1 record aanwezig is. Naast de globale velden kan je in dit bestand ook velden opnemen die standaardwaarden bevat voor de gehele applicatie.

 

BV: Algemeen bestand heeft de naam: Instel.fp5

Sleutelveld: Linker, berekening, in index, met vaste waardë 1.

Vervolgens ook in jouw bestanden het veld Linker opnemen als rekenveld met de vaste waarde 1 en de relatie leggen.

 

Overigens heeft AvD gelijk dat je niet bang moet zijn om veel velden te krijgen in een database. Wat ik zelf doe is de invoervelden en de rekenvelden en de globale velden van elkaar splitsen door middel van een naamgevingstandaard. De naam van alle rekenvelden beginnen met "_" (underscore) en die van datavelden met "__" (twee maal underscore). Op deze manier krijg je een overzicht (sorteer de namenlijst op veldnaam). Met dank aan Peter Wagemans voor deze standaardtip.

[pjotter]

nou AdV bedankt voor je cru () antwoord,ik ga nog steeds uit van zou min mogelijk velden vanuit mijn acces achtergrond. Maar als dat geen probleem is hou ik het liever zoals het is want het werkt allemaal wel en is inderdaad makkelijk uit te bouwen. Uit je antwoord begrijp ik dat ik eigenlijk best nog meer velden zou kunnen maken. De kans bestaat dat ik naar 150 velden ga is aanwezig maar zal geen probleem opleveren. De opmerking van theo2 zal ik echter meteen doorvoeren want ik kom er wel achter dat het telkens lastig is om het juiste veld te vinden en met die tip kan het inderdaad sneller omdat alles dan duidelijker wordt.

[Dr_Flash]

(...)vanuit mijn acces achtergrond. (...)

 

Ah, daar wringt de schoen

[AvD]

Hé, Flash, jij durft tenminste luidop zeggen wat wij alleen maar denken. Maar je hebt gelijk: FileMaker heeft - vanuit zijn verre oorsprong - steeds een specifieke plaats nagestreefd tussen alle databank-software. Één van de allereerste opties was de gebruiker niet lastig te vallen met de keuze van het key field (het veld waarop snel gezocht zou kunnen worden via de index-sequentiële techniek). Bij Claris vonden ze toen dat maar elk veld moest geïndexeerd worden, en zo gebeurde. Vanuit de aldus ontstane mogelijkheid om op ALLE velden index-sequentieel te kunnen zoeken, ontstond meteen ook de mogelijkheid om de klassieke en lastige pull technology ("Trek en sleur het eruit door actief te zoeken") te vervangen door de toen revolutionaire push technology ("Gooi het, dank zij de indexen, op het scherm, nog voor ze het hebben kunnen vragen: zo vinden ze dingen waarvan ze niet eens weten hoe ze geschreven worden"). Jammer genoeg zijn deze technieken in de beginfase alleen maar benadrukt in tijdschriften en recensies en was er zo goed als geen spoor meer van te vinden in de handleidingen, laat staan in de online help.

Anyway, laat Pjotter maar gerust doorwerken. Hij zal er geen spijt van krijgen. Bovendien kunnen we hem nu al zeggen dat hij - in tegenstelling met een ander databank-merk - niet from scratch opnieuw zal moeten beginnen als hij op een bepaald moment zou merken dat zijn structuur verkeerd is opgezet. Ook dat is een van de grote voordelen van FileMaker. Toch raad ik hem meer dan sterk aan de aanbevelingen van onze DJ te volgen. Hij komt soms wat snel uit de hoek, maar eigenlijk heeft hij meestal toch gelijk! 'Is goed dat we hem hier hebben.

[pjotter]

AvD je opmerking is precies in de roos over het verschil in techniek. Nu ik het lees denk ik meteen ja dat is het verschil. Hoewel acces zeker veel voordelen heeft (vaak "gratis" bij bedrijven omdat die het pro pakket nemen) is het lastig om naderhand even eea om te zetten. Ik heb even de velden aangepast (_) en alles wordt meteen aangepast. Kijk probeer dat maar eens bij acces, elke link begint meteen te klagen dat hij het veld niet kan vinden. Ik moet dan ook zeggen dat ik wilde dat ik meer tijd had voor filemaker want ik begin het zelfs verschrikkelijk leuk te vinden:-)

Als ik kijk wat ik nu klaar heb voor de vereniging had ik nooit op deze manier kunnen doen in acces als ik beginner was geweest.

[Theo2]

Hoi Pjotter leuk dat je zo enthousiast bent over de naamconventie. Een meer gedetailleerde naamconventie is de Hongaarse methode. Hierbij wordt het type veld (Numeric, Text, Date, Time, Container) aangeduid als onderdeel van de naam. In de naam worden tevens hoofdletters gebruikt om de verschillende woorden aan te duiden. In combinatie met de _ (Underscore) levert dat de volgende coderingen op:

 

Gewone velden

nKlantNr

tKlantNaam

dKlantDatum

hKlantTijd

cKlantPlaatje

 

Rekenvelden

_nKlantNr

_tKlantNaam

_dKlantDatum

_hKlantTijd

_cKlantPlaatje

_rKlantTotaal (resuméveld, dit is altijd een numeriek veld)

 

Globale velden

__nKlantNr

__tKlantNaam

__dKlantDatum

__hKlantTijd

__cKlantPlaatje

 

Deze conventie heeft het grote voordeel dat je direct ziet wat je met een veld kan doen, bv wel of niet rekenen. Tevens zijn de velden nu nog meer opgesplitst in groepkjes, bv de datumvelden staan altijd bij elkaar wat erg handig is.

 

Voor de liefhebbers van Booleaanse algebra: voor Booleans kan je gebruik maken van de kodering:

bKlantActief

_bKlantActief

__bKlantActief

 

NB: Een boolean bevat alleen de waarden 0 of 1 en kan (in Filemaker) het beste als een Numeriek veld worden gedefinieerd. Dit numerieke veld bevat echter alleen maar de waarden 0 of 1!

 

Zelf gebruik ik de hongaarse methode als sinds ik met Clipper programmeerde (ik geloof in 1990 of zoiets). Voor Filemaker heb ik de _ (underscore) conventie toegevoegd. Dit systeem bevalt mij prima. Kijk maar of je het bevalt.

[/code]

[pjotter]

die hongaarse methode is ook aardig en zal ik zeker meenemen in het aanpassen is meteen duidelijk bedankt.

[Theo2]

Beste Pjotter, hierbij ook een veldnamentest. Open de database en voer de test uit. Dan weet je of je veldnamen voldoen aan de naamgevingstandaard.

 

Veel succes!

TestFieldNames.fp5

[Dr_Flash]

Ik snap het gewoon niet zo. Ben meer voor duidelijke en zuivere veldnamen. Je kan anders toch ook sorteren op veldtype? Dan heb je ook alle datumvelden etc. bij elkaar staan. Bovendien (wat ik zelf het fijnste vind) kun je de veldnamen ook nog gewoon handmatig schikken en separators gebruiken (veldnaam "---" type tekst, of als je per veldtype wilt groeperen, het type van de eropvolgende groep, hoewel dat eigenlijk niet uitmaakt.). Wat is er dan onwenselijk aan mijn methode?

[AvD]

Ha Flash, dat ga ik u ne keer uitleggen, zie. Wat jij zegt klopt allemaal, maar alleen en enkel als je in Define Fields bezig bent. Vanaf het ogenblik dat je een veldnaam moet selecteren in een ander dialoogpaneel, dan ben je al die info i.v.m. globale of calculatievelden kwijt. Je separators zie je nog wel staan, natuurlijk.

Maar het liefst van al zou ik je nog gelijk geven. Als taalkundige van opleiding huiver ik voor die underscores en andere gedrochten die - onuitspreekbaar - in onze taal binnendringen...

[Theo2]

Er is niets verkeerd aan jouw methode iedereen gebruikt de methode die hij prefereert. De Hongaarse methode heeft wel een aantal voordelen tov jouw methode:

- volgorde per type en daarbinnen weer op naam;

- het handmatige schikken had ik nog niet ontdekt. Automatisch schikken gaat natuurlijk wel zo gemakkelijk.

- bij het gebruik van velden in formules etc weet je ook het veldtype. Het valt natuurlijk direct op als je zegt Set nVeldNaam = tVeldNaam. Zodra je dit programmeert weet je dat je ergens nog een velddefinitie (en veldnaam) moet aanpassen of een omzetfunctie moet gebruiken.

- Soms heb je meerdere verschijningsvormen van één veld - bijvoorbeeld: tKlantNaam (data veld), _tKlantNaam (rekenveld) en __tKlantNaam (globaal veld). Je hoeft dan niet steeds een andere veldnaam te verzinnen.

 

Mijn ervaring is dat de Hongaarse methode in de praktijk heel goed werkt - als je er even aan gewend bent. Vooral bij grotere systemen met honderden velden.

[AvD]

Mijn ervaring is dat de Hongaarse methode in de praktijk heel goed werkt - als je er even aan gewend bent. Vooral bij grotere systemen met honderden velden.

Nu schrikt Pjotter zich te pletter, of is hij daar al over heen?

 

PS Heb je een bronreferentie voor die Hongaarse methode?

[AvD]

Tof Theo, die veldnamentest. Als je er nu nog bijgezegd had dat die automatisch alle op dat ogenblik openstaande FMPro-bestanden checkt, dan had ik hier geen paar duizend waarschuwingsprompts gekregen. Heb uiteindelijk mijn ENTER-toets met tape vastgeplakt... Zal me leren steeds de 50 files limit van FileMaker uit te dagen...

[Dr_Flash]

Maar AvD toch, JIJ of all people hebt toch zeker wel je veldnamen in orde volgens De Norm?

[AvD]

...

(twijfel tussen "oops" en "evil")