# SQL database structure recommendations

**URL:** <https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234>\
**Category:** Ignition\
**Created:** [March 19, 2020, 1:52am UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234 "2020-03-19T01:52:45Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![john.eichler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/john.eichler/32/24632_2.png) [@john.eichler](https://forum.inductiveautomation.com/u/john.eichler)\
**Post date:** [March 19, 2020, 1:52am UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/1 "2020-03-19T01:52:46Z")

</div>

Ignition 8, MSSQL

Hi All

Our ignition installation is in its infancy and I want to get the SQL database structure right at the start.

The factory is split into approximately 6 departments, with around 4 manufacturing cells per department, each containing a number of machines or other assets. Eventually, we will be aquiring data from most of the assets.

I currently have two schema, one is used as a historian (ignition tag historian) and the other is used for storing batch data for use in various reports.

 ![943315](https://us1.discourse-cdn.com/inductiveautomation/original/2X/3/3c990afa6f2b5ee89e2470c6cbb145ab85366853.png)

Are there any recommendations for a good database structure for the setup above? Should I have a schema for each manufacturing cell and set this as its own historical data provider? I ask because I see the potential for issues with the current arrangement when we are logging all historical data to 1 schema.

Any advice would be great. Thanks.

---

<div class="post-metadata">

**Author:** ![wpmccormick](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/wpmccormick/32/13940_2.png) [@wpmccormick](https://forum.inductiveautomation.com/u/wpmccormick)\
**Post date:** [March 19, 2020, 2:59pm UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/2 "2020-03-19T14:59:10Z")

</div>

I don’t see what having separate schemas for department historical data buys you. What potential issues do you see with a single schema for tag history?

Based on what you have shared, I think separating batch data into another schema makes sense because this schema couldn’t be automatically restored by Ignition.

I would probably make 2 schemas for the factory: 1 for tag history, and another for batch data.

---

<div class="post-metadata">

**Author:** ![David](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@David](https://forum.inductiveautomation.com/u/David)\
**Post date:** [March 19, 2020, 5:15pm UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/3 "2020-03-19T17:15:04Z")

</div>

There are lots of discussions on the sql server forums about schemas and their uses, and most of the pros I have found reliable tend to not use schemas much, if at all. We don’t use them, and have many very large applications running. They primarily are useful for segregating users by permissions – is this a problem for you and this app? I notice in your snip above that you have identically named tables, in different schemas. That looks to me like a headache waiting to happen.

---

<div class="post-metadata">

**Author:** ![john.eichler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/john.eichler/32/24632_2.png) [@john.eichler](https://forum.inductiveautomation.com/u/john.eichler)\
**Post date:** [March 19, 2020, 6:33pm UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/4 "2020-03-19T18:33:38Z")

</div>

Thanks to you both for the input. It sounds likle the recommendation is to keep the SQL setup as it is. I guess I was concerned that with significantly increasing the number of historical tags, the table size could become an issue. From the above it seems like this is not a concern. David, I can’t see 2 tables with the same name. The intent was to avoid this.

---

<div class="post-metadata">

**Author:** ![David](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@David](https://forum.inductiveautomation.com/u/David)\
**Post date:** [March 19, 2020, 11:12pm UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/5 "2020-03-19T23:12:21Z")

</div>

On closer look, I see you’re right. All are under the dbo schema, and there are prefixes to distinguish the manufacturing cell.

---

<div class="post-metadata">

**Author:** ![wendy\_lawrence](https://avatars.discourse-cdn.com/v4/letter/w/9fc29f/32.png) [@wendy\_lawrence](https://forum.inductiveautomation.com/u/wendy_lawrence)\
**Post date:** [November 22, 2021, 11:36pm UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/6 "2021-11-22T23:36:53Z")

</div>

Your SQL database structure doesn’t look so bad yet. My databases are not clear where it is not clear why. Do you happen to know how to sort all databases automatically?

---

<div class="post-metadata">

**Author:** ![john.eichler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/john.eichler/32/24632_2.png) [@john.eichler](https://forum.inductiveautomation.com/u/john.eichler)\
**Post date:** [November 23, 2021, 12:15am UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/7 "2021-11-23T00:15:22Z")

</div>

Hi Wendy and welcome!

I’m afraid I don’t understand your question. Please can you rephrase it?

In my setup, the schema are created manually using Microsoft SQL management studio. For the reporting data, I also manually create the tables in management studio. For the historian schema, ignition will automatically create the tables (using the default settings) once a tag is configured as a historical tag.

---

<div class="post-metadata">

**Author:** ![mdemaris](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mdemaris/32/54639_2.png) [@mdemaris](https://forum.inductiveautomation.com/u/mdemaris)\
**Post date:** [July 8, 2024, 8:40pm UTC](https://forum.inductiveautomation.com/t/sql-database-structure-recommendations/33234/8 "2024-07-08T20:40:11Z")

</div>

And this is where I have a question or two:

I am attempting to use tag history with MSSQL, but I am not sure how. I get errors stating that the table (sqlth\_drv) cannot be created.

In this particular development environment, I have a user (Ignition) that is also used for the Perspective to access the DB.

Can I, or should I, use this same user?  
Can I change the schema the tag historian will write to, instead of `dbo`?  
Are there any specific permissions required for the user, in the `Securables` tab in the SSMS?  
And besides being a member of the `ddladmin` group, (so that Ignition can create the necessary tables), does it require any other memberships?

I have been playing with the permissions and memberships but I keep getting the same error, `TagHistoryDataSourceLink`; albeit this one occurs even after disabling the tag history on the tag I am testing with. Other errors included `DatasourceForwardTransaction` and `MemoryForwardTransaction`. These two, obviously, stopped by disabling the tag history.

EDIT:  
I should also ask if I need to create a `Database Table Historian` in the `Tag History` on the Gateway, or can I just use a normal DB connection?

EDIT 2:  
Without using the `Database Table Historian`, I am able to get Ignition to create a partitioned table in the DB, but the `DatasourceForwardTransaction` error and it's table (`sqlth_drv`) still cannot be created.

EDIT 3:  
Well, it seems that the error in EDIT 2 must be related to another DB. I refreshed the tables in my working DB and found  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/7/0785cbd46d63dd37c865fe56aa6a22cb3e22d7b5.png)  
So, it appears to be working. However, I am going to test using a separate MSSQL user login rather than the same one used for actual users.
