# Script SQL or stored procedures

**URL:** <https://forum.inductiveautomation.com/t/script-sql-or-stored-procedures/26592>\
**Category:** Ignition\
**Created:** [July 16, 2019, 6:59pm UTC](https://forum.inductiveautomation.com/t/script-sql-or-stored-procedures/26592 "2019-07-16T18:59:27Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![akettner](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@akettner](https://forum.inductiveautomation.com/u/akettner)\
**Post date:** [July 16, 2019, 6:59pm UTC](https://forum.inductiveautomation.com/t/script-sql-or-stored-procedures/26592/1 "2019-07-16T18:59:27Z")

</div>

I know the question of embedded SQL or stored procedures has been around for decades, but I haven’t seen it discussed with Ignition in mind. Thought it might be interesting to hear from some experienced Ignition programmers.

I work with some people, from the days of crap HMIs that don’t understand Ignition, that think it all should be done in SPs and use HMI for just display. I think SPs make sense if we are moving large dataset around multiple tables. But 60 - 80 records and hour whats the benefit. I find Python so MUCH easier to read than SQL.

SPs do keep everything in one place, but we can do basically the same thing with UDTs, at least that’s what I have been doing. Many machines using the same UDT, thus all the same scripts.