SQL Server Performance Forum – Threads Archive
split a long table into smaller tables?
I have a table contains data for different nodes (~100).Each node contains records anywhere from a few thausands to
a million. Each node program is interested in its own
data only. Even though I have a combo clustered index on this
table, is it a good idea to split this table into
pieces, each piece will contain data for only one node,
each piece (table) will be created on the fly by the
program – when the node is created, it create the table as well?
Thanks!
Kindly, only place post in one place. Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
I agree but I thought it was a mistake placed it in the dba forum
since it didn’t generate much interest. I was hoping I could get
more help in this forum instead.
quote:Originally posted by [email protected]
Kindly, only place post in one place.
Luis Martin
…Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
Bertrand Russell
In this case, please send e-mail to Topic Moderator to help you.
Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
Will do that. Thanks.
quote:Originally posted by [email protected]
In this case, please send e-mail to Topic Moderator to help you.
Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
But as you said you have 100 nodes .
are you ready to create 100 tables?
won’t it cause a problem in code
or scalability
Yes we could have up to 100 nodes. The question is now:
is it better to hit one single table from up to 100
nodes (table lock issue), or one node hits one smaller
table (no lock issue)?
quote:Originally posted by kate_for_u
But as you said you have 100 nodes .
are you ready to create 100 tables?
won’t it cause a problem in code
or scalability
are you ready to create 100 tables?
won’t it cause a problem in code
or scalability
You have benefits in both ways.
If one table, easy to mainteinance but lock issue.
If 100 tables, hard to mainteinace and no lock issue.
What do you think about above? Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
I probably should take a hit in maint and performance,
than potential trans failure due to lock (which
has perf problem as well)
quote:Originally posted by [email protected]
You have benefits in both ways.
If one table, easy to mainteinance but lock issue.
If 100 tables, hard to mainteinace and no lock issue.
What do you think about above? Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
If one table, easy to mainteinance but lock issue.
If 100 tables, hard to mainteinace and no lock issue.
What do you think about above? Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
Agree Zackhu.
Luis Martin …Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true.
Bertrand Russell
As far as the problems in code, if you create an updateable partitioned view the code should never be the wiser that you created 100 tables instead of 1.
]]>