Sql server table with multiple columns

Question

Need some input I need to create table with colprimkey1,col2,colyear,day1,day2,day3,...day366 like this(to have less records otherwise will be ending with billion records) in azure/synapse will it better for DML mainly updates and give better performance(This will be unpivoted later) rather then the same table having like

colprimkey1,col2,colyear,dayofyear,daydata then 1,xx,2020,'day1',88 1,xx,2021,'day4',28?

I am trying colprimkey1,col2,colyear,day1,day2,day3,...day366 1,xx,2020,88,10,34,28,...41

Any other suggestions for efficiency,storage, performance etc Thanks in advance

I tried with small data and but not in big scale only think considering is it will reduce the number of records in table but column wise more data will be there.

if anyone worked in similar situation and got better solution let me know

Answer 1

if anyone worked in similar situation and got better solution let me know

Yea, I've worked with multi-terabyte tables with 10s of billions of rows in each of those tables.

Any other suggestions for efficiency,storage, performance

Don't trade rows for columns. Architect your tables properly and use the appropriate indexing designed after the types of queries you plan to run.

will it better for DML mainly updates and give better performance

Nope, in fact it might be worse for performance, especially when trying to search multiple columns or piecing the data back together.

A B-Tree index has an O(log(n)) search time complexity. If your table had 1 billion rows, in the worst case log2(1 billion) = 40. That's only 40 nodes that would need to be seeked through to find any subset of data you're searching for. If your table grew to 1 trillion rows, log2(1 trillion) = 50 . My graphing calculator could seek through 50 nodes in under a second, any modern computer in a few milliseconds or less.

If you plan to do aggregative type of queries, then a columnstore index may be even more efficient for you from both a compression standpoint and from batch mode operations.

If you split your rows into multiple columns, you lose the efficiency gains of the above, and need to write more complicated queries to search and reshape the data. An unpivot operation on billions of rows will take a very long time.