# Organizing SQL tables and named queries efficiently

**URL:** <https://forum.inductiveautomation.com/t/organizing-sql-tables-and-named-queries-efficiently/53212>\
**Category:** Ignition\
**Created:** [November 17, 2021, 9:45pm UTC](https://forum.inductiveautomation.com/t/organizing-sql-tables-and-named-queries-efficiently/53212 "2021-11-17T21:45:15Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\
**Post date:** [December 1, 2021, 9:43pm UTC](https://forum.inductiveautomation.com/t/organizing-sql-tables-and-named-queries-efficiently/53212/11 "2021-12-01T21:43:07Z")

</div>

I am still learning how to analyze the structure of my transaction groups, tables, and named queries.  
I was convinced the other day that one big table is better.  
Today, though, I guess I don’t understand again.

**Option 1**  
One huge table, all events, all machines

Columns:  
ndx, machine, event code, quantity or duration, t\_stamp

Pro - one big table, all the machines, all the codes make it easy to parametize  
Con - table will be huge

**Option 2**  
one table of events per machine

Columns:  
ndx, event code, quantity or duration, t\_stamp

pro - smaller tables, faster queries?  
con - a different named query for every machine

**Option 3**  
A table for uptime events  
A table for rejection events  
Each of these for each machine

columns  
ndx, downtime code, duration, t\_stamp  
ndx, rejection code, quantity, t\_stamp

pro - smallest tables? fastest queries?  
con - named queries for each machine

---

_[View the full topic](https://forum.inductiveautomation.com/t/organizing-sql-tables-and-named-queries-efficiently/53212)._