<div>
How urgent is that?<br />
You can always script the add columns command and schedule it to run it during the night so tomorrow when you return the new columns are already there and the users won't suffer with the impact.
</div>


<div>
Approach.... Do this when the impact is very less.<br />
<b><br />
1. Create a NEW Table with all fields ( old + new )<br />
2. Move data from old table to new table.<br />
3. Rename the old table to some other table. Here you have consider the dependencies to other objects for time being.<br />
4. Rename the new table to old table.</b>
</div>


<div>
Sorry this is a long term solution so I'm worried about overall performance of this big table with so many columns
</div>


<div>
What do you mean with long term solution? Are you going to add more columns to the table regularly?
</div>


<div>
You have 47 columns in a table which is not huge in terms of huge databases. It is also depends on the queries you wrote on top of this table. So it all depends. <br />
<br />
If you consider that your table has large number of columns then you already have 38 columns.
</div>


<div>
You should be fine. But what you should be looking into is Indexing after you add the columns. I have had tables with 300 columns and millions of rows. Try getting list of all the queries users or process run and based on that add indexes. Do not just keep adding indexes but use your best judgement. <br />
&nbsp;<br />
If you feel space is going to be an issue and you may have NULL values in some of the columns you should look into sparse columns. You could go upto 10,000 columns on a table, and if the data is NULL it uses 0 bytes untill filled. <br />
<br />
But there are limitations check out MSDN for sparse columns.
</div>


<div>
Try out the approach I mentioned @ the top. 47 columns should not create any issues.<br />
<br />
Enjoy!
</div>


<div>
Creating new tables to move data between them it's really the last thing you should do. This can mess an entire database so be very careful if you want to go through this path.
</div>


<div>
It depends. &nbsp;How many bytes are in the row now? &nbsp;How many bytes will the new columns add per row?<br />
<br />
For example, adding 9 bit columns would have almost no impact on the performance of the table. &nbsp;Adding 9 varchar(8000) columns could destroy the performance.<br />
<br />
You could add the columns initially by using a separate table to store them, keyed exactly the same as the original table. &nbsp;Then you could:<br />
1) rename the original table<br />
2) create a view with the same name as the original table that combines the data from both tables.<br />
<br />
As to performance, <b><u>the critical thing</u></b> for best <b>overall</b> performance is to have <b>the best clustered index</b> on the table. &nbsp;Determining what that is will require reviewing index stats. &nbsp;But now would be a good time to do that, since you need to make some rather big changes to the table anyway.
</div>


<div>
Thanks, how can I share index stats?
</div>


<div>
Hi Scott<br />
I've attached the results as requested<br />
<a href="https://filedb.experts-exchange.com/incoming/2016/10_w41/1120217/ScottDbResults.xlsx" target="_blank" class="file-inline" title="scottresults (42 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>ScottDbResults.xlsx</a>
</div>


ScottDbResults.xlsx

<div>
Sorry, I've been busy, and analyzing indexes is a complex task. &nbsp;I will get back to this by tomorrow at the latest.
</div>


<div>
any update?<br />
thanks for your time
</div>


<div>
Wow, sorry, let this slip by me. &nbsp;Btw, feel free to remind me sooner, esp. when I'm this late!
</div>


<div>
Would like to hear from the author if this issue has been solved by the creation of the indexes.
</div>


<div>
<div class="content wysiwyg-content">
I have a table with 38 columns<br />
I now need to add another 9 columns or more<br />
or move them to a separate table<br />
<br />
The table has millions of rows and is accessed quite a lot (like every 30 secs by 200 users), so i'm thinking by adding more columns to this table will really impact performance, but i'm not sure<br />
can someone help clarify is this is a big NO NO or whether it will be fine adding these on same table
</div>
</div>


I have a table with 38 columns
I now need to add another 9 columns or more
or move them to a separate table

The table has millions of rows and is accessed quite a lot (like every 30 secs by 200 users), so i'm thinking by adding more columns to this table will really impact performance, but i'm not sure
can someone help clarify is this is a big NO NO or whether it will be fine adding these on same table

table size and performance

Microsoft SQL Server is a suite of relational database management system (RDBMS) products providing multi-user database access functionality.SQL Server is available in multiple versions, typically identified by release year, and versions are subdivided into editions to distinguish between product functionality. Component services include integration (SSIS), reporting (SSRS), analysis (SSAS), data quality, master data, T-SQL and performance tuning.