We’ve been looking at ways to speed up our database access and have looked at moving towards our database objects having lists of other objects in them to reference as opposed to doing lookups of the entire database.
For example, our agent object may have a list of trouble tickets as part of their database records, instead of doing a search of all trouble tickets searching for those that have the agent listed as the ticket owner.
Has anyone run in to any limits on size on this practice? In other words, If I have a user with a list of 300 other objects as one of the fields, is this going to cause a new host of problems?
I dont think there is a limit on the list. But i can tell you from experience that creating lists instead of searching through the whole database has been MUCH faster for me. So i would agree with your method for faster look ups. I try to do all my look ups through a list. For example, each student has their own list of classes and each class holds their list of students, etc.
It seems like the logical way to handle the records for sure. Thanks for sharing your experiences!
Last I knew there was a limit of 10,000 on the list.
In general the optimal way to structure things depends exactly on how you will use it, if it is meant to scale to thousands of items will be better in the long run to use Do a Search for and put all the constraints on the Search and try to avoid the :filter, as it slows it down
Some general info on using lists and performance in general can be found here:
Geoff | Wolfer Tech
The Best Selling Bubble Template
The Most Used Bubble Template (FREE)