If I have a large table with a column which has a rather limited range of values (e.g. < 100), is it reasonable to divide this table into several tables with names tied to that column value?
E.g. a table like with columns:
table "TimeStamps": [Id] [DeviceId] [MessageCounter] [SomeData]
where [DeviceId] is the "limited range" column would be separated into several different tables:
table "TimeStamps1": [Id] [MessageCounter] [SomeData] table "TimeStamps2": [Id] [MessageCounter] [SomeData] ... table "TimeStampsN": [Id] [MessageCounter] [SomeData]
The problem I am having with my original table is that finding a largest MessageCounter value for some DeviceId values takes really long time to execute (see this post).
If tables would be separated, finding a maximum column number should be an O(1) operation.
[Edit]
Just stumbled upon this, thought I would update it. The problem I originally brought me here was performance issues when querying the original database. However, after adding additional db indexes and scheduled index reorganizing jobs, I was able to get great performance with the normalized form. SSMS Database Engine Tuning Advisor tool was of great help for identifying bottlenecks and suggesting the missing indexes.
While you could do it as a last-ditch performance optimization, I would advise against it. Mainly because it makes it very difficult to accomodate new DeviceIDs.
At any rate, doing this should not be necessary. If there’s an index for DeviceID, the DBMS should be able to filter on it very quickly. That’s what a DBMS is for, after all…