FM sökningsprestanda - tips

Det finns massa saker man kan göra!

Som du vet så förbättrar indexering sökhastigheten oerhört mycket, så det betyder att alla fält som är/kan indexeras skall indexeras. Det gör alltså FileMaker så fort du har gjort en sökning i fältet helt automatiskt, men du kan även kryssa för detta själv.

Vad som slöar ner är som du märkt beräkningar allt som inte kan lagras tex beräkningar som använder relaterade data och sortering i portaler eller poster som sorterar relaterade fält.

Det finns flera lösningar, den enklaste är förstås är att faktiskt lagra informationen ifråga om det går. Ett sätt att göra det är att via manus (FileMaker-snurror, sök på detta begrepp här i forumet) som läser av relaterad information och sedan lagrar den i ett verkligt fält. Kör man detta manus lite då och då (tex på nätter) så påverkar det inte det dagliga arbetet.

En annan lösning är att lagra data på andra sätt och en tredje är att bygga en workaround, den senare är när man helt enkelt skapar en lösning som går förbi ett olösligt problem istället för att lösa det, därav namnet.

Här är en lösning på just ditt problem med att hitta unika värden i tre miljoner poster: Om du skapat beräkningar som utgör både vänstra sidan av relationen och som är kombination av två fält som i sin tur är relaterade kan resultatet inte lagras. Därmed måste FM beräkna denna info varje gång den skall visas och med tre miljoner poster tar det tid. Jag gissar att du redan provat och misslyckats med att söka på ! i flera fält för att på det viset hitta dubbletter och då upptäckt/insett att denna sökning inte hittar dubbletter värden för flera fält. Men det betyder inte att sökning på ! inte kan användas för att lösa ditt problem. Skapa ett nytt textfält, kalla det unikt_kombivärde, tag sedan och fyll detta fält med en kombination av flera fält (du kan använda ett manus som loopar igenom alla poster eller klicka i fältet, välj Poster > Ersätt fältinnehåll, ange en beräkning (Namn & Telefonnummer) tex. Markera att fältet skall vara indexerat i fältdefinitionerna, vänta ett tag. Tag sedan och sök på ! i det fältet, då får du alla dubbletter, dvs alla icke unika värden. Välj Poster > Visa uteslutna så visas alla poster som INTE är dubbletter, dvs dina unika värden.

Lycka till!

Om du söker på ! så hittas dubletter, det är alldeles riktigt.

När du har gjort en sökning på dubbletter så står det kanske Hittade: 17027 och Totalt: 433326. Om du då väljer i menyn "Poster" alternativet "Visa endast uteslutna" visas istället alla de poster som inte hittades av din sökning på dubletter, det betyder ju att det är unika poster. Är du med?

Sökning på ! hittar alla poster som har samma värde i ett visst fält som någon annan post, det betyder att även tre, fyra, fem eller 857 poster som har samma värde i fältet kommer att visas. De poster som visas är alltså dubletten och "originalet" om du förstår vad jag menar. FileMaker gömmer alltså inte undan en post av ett "set" med dubbletter och visar dubbletterna för sig. Exempel, säg att värdet 857 förekommer i fältet "Kundnummer" tre gånger och värdet 9282 förekommer 12 ggr och värdet 72727 förekommer två gånger. En sökning på ! ger alltså 17 hittade poster.

Om du söker på dubbletter och sedan sorterar på det fältet du sökte i, så ser du exakt vad som hittats.

Sedan finns det ett manus som FM utvecklare har i backfickan och återanvänder ständigt, det är ett manus so hittar dubbletter genom att loopa igenom alla poster. Jag tror jag har beskrivit det i en tidigare tråd här?

Jag vill bara kort kolla att du fattar en sak som jag beskrivit ett par gånger nu men som jag inte ser av dina svar att du refererar till eller verkar förstå?

Om du söker på dubbletter genom att ange ! i ett fält, så hittar du dubbletter, det är du med på?

Om du omedelbart efter att du har gjort en sådan sökning väljer "Poster > Visa endast uteslutna" så får du fram alla poster som INTE är dubbletter, dvs alla unika värden, är du med på det med?

Bekräfta gärna detta innan jag ger mig på att berätta lite mera.

Ett exempel kanske förtydligar det hela, säg att en tabell innehåller

A
A
B
C

Söker du på ! i fältet så hittas två poster, som båda innehåller A, undangömda är då är två poster, B och C. Väljer du "Poster > Visa endast uteslutna", så göms de två posterna med A och istället visas två poster med B respektive C, dvs de unika värdena i denna tabell i det fältet.

Ok, ledsen men det verkar som om jag fortfarande misslyckas med att förklara detta för dig. Jag är helt med på att du vill göra en select distinct, precis som i SQL och jag fattar att du förstår att om du söker på ! så hittas alla värden som INTE är unika. Precis så här långt tror jag du är med.

Men vad du fortfarande inte indikerar för mig (jag missförstår dig säkert) är att du förstår genom att välja "Poster > Visa endast uteslutna" direkt efter att du har sökt på ! så får du fram alla värden som ÄR unika, dvs exakt den Select Distinct som du är på jakt efter. Dvs alla värden som inte hittades av sökningen på !. Alla poster som visas då är nämligen de som har unika värden.

Vill du ha dessa värden i en lista i ett fält eller annorstädes så finns det enkla metoder för det, men det är steg två.

Ok, du har helt rätt, A är ju inte med när man flippat sökresultatet från dubbletter till icke dubbletter. Återkommer lite senare med mera FileMaker-finesser och metoder att få fram verkligt unika värden och kanske något annat tips som handlar om hur du kan få en toksnabb databas även om den innehåller miljoner poster.

Hur vill du använda de unika värdena? Ska de exporteras till något slags lista för användning i något annat program etc? Eller vill du att en uppsättning poster ska visas, och i så fall undrar jag vilken instans av dublettposterna som ska visas? (dvs. om värdet X förekommer i tre poster, vilken av dessa tre poster ska visas?)

Glömde en vanlig metod för punkt 3 som är ganska snabb för att hitta "nästa lediga nummer". Man skapar ett manus som:
1. Visar alla poster.
2. Sorterar på numret.
3. Går till sista posten
4. Läser av numret, lägger till 1 för att skapa nästa lediga nummer.

I ditt fall med en miljon poster är den kanske inte så snabb, men den borde vara snabbare icke beräknade relationer i alla fall.

Ännu en metod är förstås att lagra priskoder i en separat tabell och generera dessa före de används och när man behöver en, ta en ur tabellen och markera den som använd. Detta går att göra med några enkla manussteg:

För att skapa koder (pseudkod för FileMaker):

Gå till tabellen/layouten, Bearbeta

Ladda en räknare med ett värde, tex 10.000 (dvs ett variabefält, numeriskt, i FM 8.5 finns även manussteget skapa variabel som kan användas i manus.)

Starta en loop, skapa en post, tilldela posten en kod (här skall det vara någon knasig beräkning som skapar koder baserad på någon komplicerad räkneövning med checksiffror och allt, tänk tex serienummer för programvaror, OCR-nummer och liknande).

Räkna ner ett från räknaren

Om räknaren är noll, lämna loopen (Exit loop if-steget)

Avsluta loopen.

För att läsa av en priskod:
Skapa ett beräkningsfält i priskoder som är baserat på villkoret att om denna posts nummer är använt, så är värdet tomt, i annat fall, så innehåller det X.

Skapa en relation mellan tabellen där priskoden skall läsas av på ett beräkningsfält som alltid innehåller "X" och priskoder på beräkningsfältet ovan.

I ett manus läs av priskoden via relationen och märk den som använd när det är gjort via denna relation. Dvs via tilldela fält.

Det fungerar så i FileMaker att om en relation ger flera hittade poster "där borta" så kan FileMaker mycket väl och enkelt jobba med den första posten via relationen, när den är markerad som använd slår villkoret i beräkningen till ovan och då är den posten inte först längre och försvinner så att säga, och ersätts med nästa oanvända. Fiffigt eller hur?

Okej, jag är ingen FM-expert, men jag kan en eller två saker om AppleScript och ShellScripting, och där är en sån här sak lätt att lösa, så följande script hämtar alla unika värden, läser av det högsta, ökar med 1 för att få nästa lediga unika värde, och stoppar in värdet i angivet fält på aktuell post.

"set cellValue of cell \"Målfält\" of current record to (paragraph -1 of (do shell script \"echo '"  & List(kasta 2::Källfält) & "' | tr '\\\r' '\\\n'  | sort -n | uniq " & "\") as integer +1)"

Det man behöver ändra för att köra det i sin egen databas är att man behöver en självrelation som alltid ger alla poster (x) och byta ut den del av min kod som heter "kasta 2::Källfält"

Likaså behöver man ändra namnet "Målfält" till namnet på det fältet i den egna databasen där man vill stoppa in resultatet

Hur det står sig prestandamässigt vet jag inte. Själva AppleScript/Shell-delen är löjligt snabb men hur snabbt FM hämtar data via List-funktionen beror ju på om dessa redan är indexerade etc

Fördelen med scripting (i det här fallet) är att man kan komma åt kommandot "uniq" som ger precis det du vill. För att Uniq ska funka som det ska måste det först köras genom "sort" som sorterar listan". Sort i sin tur kräver att alla radbrytningar är unix-radbrytningar, vilket är vad kommandot "tr" i mitt fall gör.

Att man behöver använda AppleScript är bara för att FM kan utfärda AppleScript-kommandon, men inte direkt shell-kommandon. Alltså använder mitt exempel AppleScript bara som en brygga.

Att det ser så krångligt ut är bara för att såväl FM som AS och Shell kräver att man "escapar" alla specialtecken, därav alla backslashes etc

Syntaxen kanske ser lite krånglig ut men logiken är enkel

* Hämta alla värden (FM)
* Byt ut alla radbrytningar (Shell)
* Sortera listan (Shell)
* ta fram unika värden (Shell)
* Ta sista (högsta) värdet och öka med ett (AS)
* Stoppa in värdet i en cell (AS)

Jo förresten, det finns en gratis plugin för att FileMaker skall kunna utföra shellscripts.

http://www.abstrakt.com/shell.html

Jag tänkte svara på de senaste inläggen men har inte haft tid.

Posten du står i (en post) "tittar via" en relation aka "ett titthål i väggen" (eller vilken metafor du nu vill använda) och "ser" ett antal poster via denna relation, alltså tre poster.

Det är inte så att tre visade poster samtidigt tittar genom samma relation samtidigt och var och en av dessa tre poster ser samma tre poster, totalt nio poster. Det finns ju inte nio poster, det finns ju tre.

Relationer utvärderas i den kontext du befinner dig och det är layouten (vilken tabellförekomst den visar poster från) och posten du står i och var den befinner sig i relationsdiagrammet.

Det finns ett manussteg som är ett frånsteg från denna regel: "Gå till relaterade poster", där man kan ange "Visa endast relaterade poster" med de två underalterantiven:

* Matcha endast relaterad post
* Matcha alla poster i aktuellt sökresultat

Den första betyder "Jag står på en post, det är bara dess relaterade poster jag vill hitta via relationen när jag hoppar dit", den andra betyder "Jag står på en post och brevid mig finns några till, ett helt gäng faktiskt, när jag hoppar via relationen så vill jag och alla mina kompisar som jag kallar för "hittade poster", se alla relaterade poster där borta, vi tar med chips, dip och vodka och så har vi en fest!" om man nu skall uttrycka sig i tekniska termer...