|
|
Like this article? PLEASE +1 it! |
|
Good Example of Poor Scalability
|
| Guest post by: Christopher Lowe |
Article Overview: A well-built FileMaker Pro database will have the ability to maintain its speed and usability over time while managing an ever-increasing number of records. When best practices are not applied, they can slow a database to a crawl under the most modest circumstances. This is the concept known as scaling.
![]() |
Free Download - Being Agile, Flexibility is Key! By Christopher Lowe |
Good Example of Poor Scalability
So today a client comes to me saying they decided to use the Music Library starter solutionthat ships with FileMaker Pro to track their production department’s immense CD vault. It’s a simple template featuring a typical parent/child relationship between albums and tracks.
The problem was that every time they added a new record and entered the artist and title, it ran a replace upon exiting the field that was taking longer and longer – we’re talking up to 10 seconds and growing – with the dialog box indicating there were 96 records remaining. That was very interesting, since they’d only entered 40 album records thus far, each with a multiple number of tracks.
Upon close examination of this start solution, I was shocked to find the reason behind this. The “Artist” and “Title” fields have script triggers that execute upon exiting, both pointing to the same script. That script had two steps: replace all track records’ IDs with themselves, and then commit records.
Each time they exited a field, each and every track record was being updated. This was totally unnecessary, and was causing the solution to buckle under its own weight.
So first, we have to understand why the related track records need updating at all.In this template, some of the data fields for an album are copied to its child tracks. This may or may not be necessary for their particular purposes, but it’s just how this template was built. Now, two of those things that a track record grabs from its parent album when entered is the artist and title. If one should later change the album’s artist or title details, the child track records normally would not be updated automatically without some sort of mechanism in place, such as a script. So they would potentially contain different information than their parent record, when they should be identical.
So really, there’s no reason why EVERY track record should be updated when a title or artist is entered, just the tracks (if any) for the current album being edited. By adding a few script steps, we were easily able to speed up the data entry process and still satisfy the need to keep track records up to date. The modified script now first tests to see if any track records exist for the current album, and if so uses a GTRR step to find those records and runs the replace step just on those records, then commits and goes back to the original layout. So entering records is now as fast as you’d expect. And if they modify an artist or title for an album that contains track records, there will be only a slight pause that is barely noticeable. The best part is: no matter how many records are entered, that occasional pause will never increase in duration.
So the lesson here is: just because you saw it in a FileMaker Starter Solution, doesn’t mean it represents best practices. Of course, there is a whole separate issue here about whether the Replace function should be used in this situation or not due to record-locking implications in a multi-user environment. But that’s for another time…
Article Tags: database design, database scalability, filemaker, filemaker pro
|
About the Author: Christopher Lowe RSS for Christopher's articles - Visit Christopher's website Christo began his career in technology back in 1986, when he was given his very first Macintosh Computer to write a database solution for the Photo/Graphics department of Notre Dame University. Since then, he has had the opportunity to work with various large and small companies as a consultant, an employee, and a manager dealing with several computer platforms and a plethora of database and networking technologies. Christo has a unique way of understanding the needs of organizations and companies, the individuals, and departments within those entities. After working for several consulting firms both small and large, he decided to start his own company, Excelisys (www.excelisys.com), with a strong emphasis toward customer service and quality. He continues to build a team of loyal and devoted people who have the same common goals, passions, and insight into building intuitive custom information management systems for use in client/server, WAN/LAN, Web, and Mobile deployment strategies. Click here to visit Christopher's website By the Hour or Not by the Hour THAT is the Question Being Agile Flexibility is Key Drag and DropDead Elegant Interfaces TipsnTricks AsYouType Search Filtering using Script Triggers Good Example of Poor Scalability |
Related Forum Posts
Share this article with your friends. Fund someone's dream.
Leave a comment below or share on the left and you'll help support entrepreneurs in Africa through our partnership with Kiva. Over $50,000 raised and counting - Please keep sharing! Learn more.
Get advice & tips from famous business
owners, new articles by entrepreneur
experts, my latest website updates, &
special sneak peaks at what's to come!
The Basics Of A Home Based Internet Business
Tips to Take Control of Credit Card Debt
How to Ask for a Flexible Work Arrangement
Email us your ideas on how to make our
website more valuable! Thank you Sharon
from Toronto Salsa Lessons / Classes for
your suggestions to make the newsletter
look like the website and profile younger
entrepreneurs like Jennifer Lopez.



