Relaties over meerdere tabellen: geen sortering mogelijk

[sefanja]

Het lijkt erop dat FileMaker geen records kan sorteren als een relatie zich over meerdere tabellen uitstrekt. Een voorbeeld:

 

Drie tabellen:

• Rooms
  
  • RoomID
    
  • RoomNumber

  [*]Users

  • UserID
    
  • UserName

  [*]Reservations

  • RecordNumber (auto increase)
    
  • RoomID
    
  • UserID

 

De volgende relaties zijn aangebracht:

• Rooms::RoomID = Reservations::RoomID
  
• Users::UserID = Reservations::UserID

 

Omdat ik wil dat FileMaker in de verschillende layouts altijd de meest recente reservering weergeeft, heb ik in bovenstaande relaties opgenomen dat de records uit Reservations gesorteerd moeten worden op RecordNumber, van hoog naar laag.

 

Er staan twee records in Reservations:

• RecordNumber: 1
  
• RoomID: 23
  
• UserID: 100
   
  
• RecordNumber: 2
  
• RoomID: 23
  
• UserID: 200

 

Als ik vervolgens een layout maak aan de hand van de tabel Rooms met het volgende samenvoegveld:

• <>; <>; <>

 

Dan is dit het resultaat:

• 23; 200; 100

 

Het lijkt er dus op dat wanneer Rooms info nodig heeft uit Users, FileMaker geen rekening houdt met de sortering die aan is gegeven in de relatie tussen Rooms en Reservations. Voor de duidelijkheid: er bestaat geen directe relatie tussen Rooms en Users, die loopt namelijk via Reservations.

 

• 
  Rooms::RoomID = Reservations::RoomID; Reservations::UserID = Users::UserID

 

 

Is dit een fout van de ontwikkelaars van FileMaker? Of is dit gedrag opzettelijk zo bedoeld? Wat is de beste workaround?

[Jeroen Aarts]

Dit gedrag is inderdaad zo bedoeld, waarschijnlijk uit efficiëntie overwegingen. De sortering werkt dus alleen tov de TO (table occurrence) waarop ze gedefineerd is, voor TO's verder in lijn wordt de sortering niet gerespecteerd, en wordt maw de 1ste record in de ongesorteerde recordset genomen, dit is de 1st aangemaakte.

 

Ik begrijp dat dit enigszins raar overkomt als je uit een context komt van SQL databases, en je bv. gewoon bent om met views te werken (waar sortering ook een tabel/TO verder ook zou behouden blijven). Je zult ermee moeten leven.

 

In je voorbeeld kan je uiteraard de UserID nemen uit de Reservations tabel, voor andere velden moet je velden van het type calculation aanmaken in Reservation, en daarin de gerelateerde velden uit de Users stoppen.

 

HTH

 

- Jeroen

[sefanja]

Lijkt mij toch dat in dit geval functionaliteit prioriteit zou moeten krijgen boven efficiëntie? Zo lang duurt het nou ook weer niet om records te sorteren.

 

FileMaker zou een gemakkelijk databaseprogramma moeten zijn. Dit relatiegedrag ligt niet in die lijn, lijkt me. Hoe leg je een Request for Change voor bij FileMaker?

 

Heb trouwens ontdekt dat de sortering wel gerespecteerd wordt als de koppeling over hetzelfde veld verloopt. Het gaat dus bijvoorbeeld wel goed bij de volgende relaties:

• Furniture::RoomID = Rooms::RoomID; Rooms::RoomID = Reservations::RoomID

[Jeroen Aarts]

Zo lang duurt het nou ook weer niet om records te sorteren

 

Als jij het zegt. En wat als het gaat om recordsets van 100.000+ records, wat als de gerelateerd TO geen 2 maar 10 knopen verwijderd is van de basis TO?

 

Bekijk het positief: dit is de keerzijde van de ongeëvenaarde flexibiliteit die FileMaker je biedt om op gelijk welke layout in een handomdraai gelijk welke gerelateerde gegevens te tonen. Gebruik bv. portals om je bovenstaande probleem op te lossen. Tip: een portal hoeft niet te starten van gerelateerde record 1, je kan kiezen vanaf welke rij je start...

 

Voor feature requests dien je - volgens mij - lid te worden van FileMaker Technet. Via de Technet website kan je feature requests indienen.

 

- Jeroen

[Peter Wagemans]

http://www.clarify.net/viewtopic.php?t=5413

 

Helemaal onderaan staat nu ook een link naar de feature request pagina.

Weliswaar via Technet gevonden, maar de pagina blijkt in een niet beschermd gedeelte van de site te staan.

[sefanja]

Heb er een bug report van gemaakt:

1. Create 3 tables: Rooms, Users, Reservations with the fields mentioned in step 2 (Reservations::RecordNumber must auto increase).

2. Create these relations:

a. Rooms::RoomID = Reservations::RoomID (sort descending Reservations::RecordNumber)

b. Users::UserID = Reservations::UserID (sort descending Reservations::RecordNumber)

3. Fill the database with at least two records in each table.

4. Create a layout based on Rooms with these fields:

a. Reservations::UserID

b. Users:UserID

 

You'll find that Reservations::UserID != Users::UserID. It seems that FM ignores the sort order because there is no direct relation between Rooms and Users.

[rmw]

ik heb geprobeerd je voorbeeld na te maken, omdat me er iets bij staat van een verschil tussen samenvoegvelden en portals....

 

....maar zie bijgaand, ik krijg niet jou situatie.

 

Doe ik iets anders dan jij beschrijft of beschijf je iets anders dan je hebt

 

 

edit: ik deed iets anders dan je beschrijft......

 

en er IS verschil!

de context van je samenvoegveld is een andere dan die van je portal, waardoor dit verschil ontstaat.

 

misschien helpt het.

 

rmw

SortCheck.fp7

[sefanja]

Resultaat van de portal is uiteraard wel goed omdat die gebaseerd is op Reservations. Die tabel heeft een directe relatie met zowel Rooms als Users waardoor er rekening gehouden wordt met de sorteervolgorde.

 

Het (samenvoeg)veld is echter gebaseerd op Rooms en geeft dan ook een verkeerd resultaat voor Users (200=100) omdat er geen directe relatie bestaat tussen Rooms en Users. Pas dan wordt de sorteervolgorde genegeerd.

 

Een portal is in mijn geval niet handig omdat ik in de layout naast het kamernummer de foto wil laten zien van de laatste gebruiker.

[Jeroen Aarts]

Succes ermee!

 

Je situatie is wel bekend en wordt door FileMaker zelf waarschijnlijk omschreven als "expexted behavior", eerder dan als bug. Laat ons het resultaat van je report weten!

[rmw]

Resultaat van de portal is uiteraard wel goed omdat die gebaseerd is op Reservations. Die tabel heeft een directe relatie met zowel Rooms als Users waardoor er rekening gehouden wordt met de sorteervolgorde.

 

Het (samenvoeg)veld is echter gebaseerd op Rooms en geeft dan ook een verkeerd resultaat voor Users (200=100) omdat er geen directe relatie bestaat tussen Rooms en Users. Pas dan wordt de sorteervolgorde genegeerd.

 

en daarom zegt FM dus dat het verwacht gedrag is en geen fout.

 

Een portal is in mijn geval niet handig omdat ik in de layout naast het kamernummer de foto wil laten zien van de laatste gebruiker.

 

Maar het gaat je om alleen de eerste waarde toch?

En portals kunnen ook slechts 1 regel weergeven...

En de opmaak van een portal kan zo worden ingesteld dat je hem niet ziet...

 

rmw

[sefanja]

Natuurlijk kan het op andere manieren ook, maar elke workaround maakt het programma ondoorzichtiger. (Momenteel gebruik ik de goede tip van Jeroen Aarts in bericht 2.)

 

Als FM dit gedrag echt zo bedoeld heeft, ben ik teleurgesteld in de ontwikkelaars. En wat me dan vooral tegenvalt, is dat dit gedrag niet duidelijk gedocumenteerd is.

 

Ik zou bijna denken dat ze (achteraf?) zeggen dat het zo bedoeld is omdat ze dan geen prioriteit hoeven te geven aan deze bug.

 

Dit vreemde gedrag past toch onmogelijk in hun filosofie om de ontwikkeling van database-gebaseerde toepassingen eenvoudig te maken?

[rmw]

Als FM dit gedrag echt zo bedoeld heeft, ben ik teleurgesteld in de ontwikkelaars. En wat me dan vooral tegenvalt, is dat dit gedrag niet duidelijk gedocumenteerd is.

 

Volgens mij (maar dit forum is eigenlijk niet voor meningen...) is dit een typisch voorbeeld van 'computers doen wat je ze opdraagt en niet wat je wilt dat ze doen'

 

Maar ook ik neem de wijze raad van jeroen uit antwoord 2 ter harte: we zullen er mee moeten leren leven

 

rmw

[AvD]

(maar dit forum is eigenlijk niet voor meningen...)

Ik denk dat wij het daarmee niet eens zijn!

[SuperWimmie]

....Wat is de beste workaround?

 

De basis van dit probleem zit hem (volgens mij) in het ontwerp van de database. Is het rapport of layout niet te maken uit de tabel Reservations?

Zo ja, probleem opgelost.

 

Zo niet, dan zou je mogelijk een andere TO moeten maken waarin de relatie aangeeft welk van de child-records je als eerste zou willen zien.

Misschien dat de relatie op basis van >datum oplossingen biedt.

 

Zelf probeer ik in de applicatie steeds naar het laagste functioneel data-nivo te gaan en daar alles te doen. Bij een goed ontwerp zie je dat je daar vrijwel alle vragen mee opgelost kan krijgen. Vaak zonder ingewikkelde TO's, relaties, extra velden etc.

Voor zover dat mogelijk is.

[AvD]

Zelf probeer ik in de applicatie steeds naar het laagste functioneel data-nivo te gaan en daar alles te doen. Bij een goed ontwerp zie je dat je daar vrijwel alle vragen mee opgelost kan krijgen. Vaak zonder ingewikkelde TO's, relaties, extra velden etc.

 

Gouden raad!

[andries]

Zelf probeer ik in de applicatie steeds naar het laagste functioneel data-nivo te gaan en daar alles te doen. Bij een goed ontwerp zie je dat je daar vrijwel alle vragen mee opgelost kan krijgen. Vaak zonder ingewikkelde TO's, relaties, extra velden etc.

Voor zover dat mogelijk is.

 

Klinkt zeer mooi, maar zou je hier wat meer over kunnen zeggen? Ik snap het niet helemaal. ( ik ben niet zo abstract en hou graag van een concreet iets )

[AvD]

Wat je nu vraagt, Andries, is het voorwerp van een echte cursus. Ik ben benieuwd hoe jouw vraag hier snel (?), eenvoudig (?) en begrijpelijk (?) beantwoord zal worden.

Er is hier op het forum al wel een documentatiegedeelte waar je - via zelfstudie - heel wat over bijvoorbeeld normalisatie kunt leren.

Succes!

[andries]

en zo een cursus kost me

 

Ik weet dat er veel over te lezen valt, en heb me er ook al in verdiept, maar de verleiding is zo groot om snel even een extra TO aan te maken of snel even dit of snel even dat (zeker met de nodige tijdsdruk)... en na een tijdje gaat er niets snel meer... en zeker met buoys and anchors krijg je al snel een volle relational graph. Maar dit is off topic.

 

Ik moet de volgende gouden regel leren in mijn achterhoofd houden "bezint eer ge begint" zoals ze dat op zijn Vlaams zeggen.

[AvD]

Ik moet de volgende gouden regel leren in mijn achterhoofd houden "bezint eer ge begint" zoals ze dat op zijn Vlaams zeggen.

En "bezinnen" betekent: "reflecteren over kenniselementen", vrij vertaald: "nadenken over dingen die je weet". En nu zijn we bijna helemaal off topic, maar wel bij de kern van de zaak: die kennis - sommigen zeggen: "Kennis is macht" - die moet je hebben, verwerven, krijgen, kopen, stelen of je op een of andere manier eigen maken. Maar zonder kennis heeft bezinnen geen voorwerp, en dus ook geen zin.

[JeanWM]

Met wat Jeroen zei, weten we dat we zoveel mogelijk de dichtsbijzijnde gegevens nodig hebben.

 

Waar vinden we die ?

 

Jawel, op ons getekend data diagram....

Argument tegen zo'n diagram:

Het moet snel gaan....

..snel even dit..

..snel even dat...

..de nodige tijdsdruk..

Geen tijd....

 

Maar er schijnt wel tijd te zijn om te zoeken naar het waarom van een schijnbaar vreemd gedrag, wel tijd om een posting te doen, wel tijd om naar een (mogelijk) antwoord te wachten...

 

Alles even samenbrengen:

Jeroen zegt dat je de dichtsbijzijnde data dient te nemen....

SuperWimmie zegt dat je naar de basis dient te gaan en van daar vertrekken....

 

Bij iedere ophaling van data dien je je de vraag te stellen: heb ik de dichtbijzijnde data ?

 

En dat kun je enkel zien op je datadiagram.

 

Het antwoord dient ja of neen te zijn, en enkel ja of neen.

Indien je een 'ja...maar' of een 'neen...maar' als antwoord hebt, zit je nog niet diep genoeg.

 

Vind je geen directe data, dan moet je iets ondernemen om die te verkrijgen.

Je hoeft daarom nog geen TO of relatie of iets ingewikkeld te hebben.

Dat zie je dikwijls als antwoord op forums: create TO, create relationship, create...create...create...

Niemand stelt de vraag om even te kijken of de data al ergens (verborgen) zit.

 

Je kijkt op je diagram en het kan bv voldoende zijn om een veld auto enter calc te maken.....

 

Een free tip (from a course):

'Whenever business rules call for the exercise of discretionary powers, mechanisms to depart from calculated norms are called for.'

 

Euh....we hebben geen business rules....

Hoe weet je dan dat je de verzamelde data echt nodig hebt ?

Hoe weet je dan dat je echt alle nodige data hebt ?

 

En zo zijn we terug bij het begin van de creatie:

'In den beginne schiep de developer de business rules, en hij zag dat het goed was. Daarna schiep hij zijn data diagram, met als basis de BR's, en hij zag dat het goed was....'.

Toen de tevreden klant alle facturen betaald had, nam de developer de tijd om te rusten en zijn werkmethodes te overdenken om ze mogelijk te verbeteren.

Bij de volgende opdracht zag de developer dat het zelfs beter ging....

 

Als je nooit tijd hebt om het van de eerste keer goed te doen, waar ga je de tijd vandaan halen om het later over te doen....

 

Nooit......

 

En nu stap ik van mijn SunLight kist.....

[SuperWimmie]

Zelf probeer ik in de applicatie steeds naar het laagste functioneel data-nivo te gaan en daar alles te doen. Bij een goed ontwerp zie je dat je daar vrijwel alle vragen mee opgelost kan krijgen. Vaak zonder ingewikkelde TO's, relaties, extra velden etc.

Voor zover dat mogelijk is.

 

Klinkt zeer mooi, maar zou je hier wat meer over kunnen zeggen? Ik snap het niet helemaal. ( ik ben niet zo abstract en hou graag van een concreet iets )

 

Klein voorbeeldje, ik hou het natuurlijk heel simpel om het begrijpelijk te houden:

 

Een auto is 1 ding, dat bestaat uit componenten.

 

Een component is 1 ding dat bestaat uit onderdelen

 

Een onderdeel is 1 ding en dat bestaat uit enkelvoudige materialen.

 

Laagste nivo is enkelvoudige materialen.

 

Pak het wiskundig op en je ziet dat een auto een hele grote verzameling is van enkelvoudige materialen.

Mocht je dus iets zoeken, probeer dan de zoekactie los te laten op de enkelvoudige materialen, omdat je dan alle gegevens van de bovenliggende nivo's bij jouw zoekactie kan betrekken.

Werkelijk alles is mogelijk om op te zoeken EN te sorteren.

 

Blijft de vraag of zo'n top-down opbouw van gegevens mogelijk zal zijn in jouw ontwerp van het programma.

Bij mij is dit wel het streven en ik moet zeggen dat je dan tot ijzersterke constructies komt.

Mits de juiste gegevens op de juiste plaats opgeslagen liggen, uiteraard.

Maar dat maakt jou een kunstenaar als je dit goed door hebt.

[andries]

Bedankt voor het antwoord. Het is inderdaad steeds de bedoeling om hier naar te streven, maar zoals je zelf zegt: niet makkelijk. En soms moet je kiezen voor een bepaalde datastructuur ook al is die niet optimaal in AL de gevallen binnen je applicatie, maar wel voor een groot deel van de gevallen. Ik heb het vooral moeilijk met het kiezen of je gaat voor een extra zkf (foreign key) binnen een bepaalde tabel, of dat je gaat voor lange relationele paden.

 

Voor een auto is dat vrij straight forward. Maar bijvoorbeeld voor prestaties binnen projecten die gefactureerd moeten worden vind ik het bijvoorbeeld niet even makkelijk.

 

Zo heb je dan het voorbeeld dat een gebruiker graag vanuit zijn projecten zijn facturen zou willen zien. Op zich niet moeilijk, dan krijg je dus:

 

Project -< Prestaties - Factuurlijn >- Factuur

 

Maar houdt dit dan niet in dat je steeds dit hele relatiepad moet herhalen als je van project naar factuur wil. Ik hoor dan ook vaak stemmen opgaan om ook binnen de tabel Factuur een zkf_PROJECT aan te maken, om ook de volgende link te kunnen maken

 

Project -< Factuur

 

 

Dit is natuurlijk enkel geldig als binnen een factuur slechts 1 project kan gefactureerd worden, anders moet je met een multikey werken (liever niet) of met een join table ( wat dan in dit geval de factuurlijnen zouden worden) en krijg je

 

Project -< Factuurlijnen >- Factuur

 

 

Het wordt nog toffer als je ook nog is de klant er mee gaat betrekken. Elke klant heeft verschillende projecten, geeft je de volgende relatie:

 

Klant -< Project.

 

Als je nu wil zien welke facturen deze klant heeft openstaan bij jullie, kan je dus het volgende doen:

 

Klant -< Project -< Prestaties - Factuurlijn >- Factuur

 

Maar dit wordt toch al een verre relatie en maakt je relational graph zo onduidelijk (ik gebruik vaak anchor and buoy, dus heb je sowieso al een grote relationele grafiek). Dus binnen factuur moet er ook een zkf_KLANT komen zodat je dit kan doen

 

Klant -< Factuur.

 

Of je kan dan ook de zkf_PROJECT gebruiken die we reeds eerder hadden geintroduceerd tot

 

Klant -< Project -< Factuur

 

ik hoop dat het een beetje duidelijk is. en ik weet ook dat hier geen recht toe recht aan antwoord op is, maar het is een dilemma dat ik vaak tegenkom.