[Performance Design] Do Search For Vs Recorded List

Scenario -
Restaurant Order App, every Item ordered will create a data [ Ordered Item ]

  • POS (point of sale) will Do a search for [Ordered Item] that ( match with Restaurant, Payment Status, Kitchen Status )

My Question :
What if i Eliminate Do A Search, but everytime moving [Ordered Item] to a Database that record list, example
DB Restaurant
→ Unpaid Ordered Item List
→ Served Ordered Item List
→ In Kitchen Ordered Item List

So after certain workflow, i just move the [Ordered Item] into relevant List,
I no longer need Do a Search for XXX, instead just call the List from Database.

– My concern. I have about 10 restaurant now, the [Ordered Item] accumalated already 10k just 2 months and started to see slow down in certain process flow…

Open to any better suggestion.
Thanks in Advance

When you do your search, do you have as many constraints as possible for it to narrow down the search? Are you using any :filtered or other operators after the search?

the ordered list contact 10 fields, (except default field like created date )

Example search
Constrainsts = Restaurant = X, Paystatus = X

1 more question:
Filtered is done by device or Server?
Meaning search for, get all related data, but filtered done by client device?

Yes filtered is client/device side and most other operators done after the search. So for performance it’s recommended to use as many constraints in the search and format the database to take advantage of that too.


I understand that you have a performance issue because you are calling a datatype -“Ordered Item” - that is growing fast and reaching 10k+ entries at this time.

I also understand that you have a Point of Sales department that is running slow and you wish to enhance the performance of your database by restructuring your data in such a way that your POS would no longer be calling all of your Ordered Items filtered by order status but rather, based on a parent level constraint set to Order status, would be calling a split version of your data type.

In order to achieve this, one method would be to leverage satellite data types and implementing back end database triggers. It implies amendment of some of your front end workflows as well.

This is quite complex to explain so please let me know if I have actually really understood your problem, then I will dive into the solution.



hi, in general do a search for will also be fast with 1M records.
unless you use do a search for: filtered, or even worse do a search for:filtered advanced or do a search nested.

the lists so like restaurants list of items gets slower as soon as you hit more than 100 items and has a limit at 10k items.

I guess you understand correctly, but i rather to move more workload to Client-side.

I think you can assign the list datatype with type order to user and just add that to the user, than just show it on the basis of user, that way it will be superfast