# SQL Tall/Long vs Wide Table Structure

**URL:** <https://forum.inductiveautomation.com/t/sql-tall-long-vs-wide-table-structure/26231>\
**Category:** Ignition\
**Created:** [July 2, 2019, 4:36pm UTC](https://forum.inductiveautomation.com/t/sql-tall-long-vs-wide-table-structure/26231 "2019-07-02T16:36:59Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 2, 2019, 7:10pm UTC](https://forum.inductiveautomation.com/t/sql-tall-long-vs-wide-table-structure/26231/4 "2019-07-02T19:10:56Z")

</div>

I generally make tables wide enough to permit related values to share a row in a table with a single timestamp column. This is the classic transaction group. If multiple entities share that specific structure, I include a column to indicate which entity to minimize the proliferation of tables. That would be the block transaction group, though I don’t usually use it – I prefer to trigger individual rows as needed. Both of these approaches are extremely friendly to external data analysis, but need to be charted with DB pens.

Any value that is truly independent goes into the regular tag historian (tall tables). This is brain-dead easy to chart.

Note that I decide based on the _ **use** _ of the data, and make my infrastructure conform.

---

_[View the full topic](https://forum.inductiveautomation.com/t/sql-tall-long-vs-wide-table-structure/26231)._