# Help Reducing a Query **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [November 15, 2023, 2:33pm UTC](https://forum.inductiveautomation.com/t/help-reducing-a-query/81922 "2023-11-15T14:33:05Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [November 15, 2023, 3:59pm UTC](https://forum.inductiveautomation.com/t/help-reducing-a-query/81922/6 "2023-11-15T15:59:11Z")
Personally, I would probably move this to a script and build the query dynamically, and then call it with `system.db.runPrepQuery()`. Named Queries are great and should be the default solution, IMO, however, they aren't the correct solution for every situation. Let the scripting handle the logic for you, it's really good at that, and then the DB can do what it does best. See this post for more info. > [@runNamedQuery vs runPrepQuery](https://forum.inductiveautomation.com/t/runnamedquery-vs-runprepquery/81268/6): > > The original purpose of Named Queries was to make it possible to pass values into Vision Query bindings in a secure and efficient way, solving the unreliability of parameter stringification (looking at you, java.util.Date), and allowing the huge "legacy DB access" security hole to be closed. The maintenance advantages of NQs can be matched by multi-line strings for SQL in library scripts, so I tend to discount that item. However, not all is well. Some things to consider: NQs permit the use… --- _[View the full topic](https://forum.inductiveautomation.com/t/help-reducing-a-query/81922)._