SQLServer - treat table as index

What you ask for is what we call a "clustered index" in the SQL Server world. The clustered index is the data. I.e., the b-tree for the index is you actual table data.

A clustered index don't have the concept of included columns since all columns are in the clustered index - the clustered index being the data. So you have the key columns (what you use to "drive the query", like the WHERE clause, so to speak); and the rest of the columns are in the leaf.

You can think of the non-key columns in a clustered index just like included columns in a non-clustered index.

Don't confuse the PK with the clustered index. You decide whether the PK should come with a clustered index or a non-clustered index.

You might have a better candidate for the clustered index than the PK. Fine! Just make the PK non-clustered and create the clustered index on that better candidate.

As Tibor describes in his answer, what you are looking for is a clustered index with a wide key. If all you need is this index then that will do the job exactly as you want with no extra storage needed.

There is a space consuming danger with wide clustering keys though: any supplementary non-clustered indexes will include the clustering key. So in this example if you later add an index on only value you effectively have an index containing everything again (i.e. your original concern). Off the top of my head I'm not sure if this would behave as an index on value including location, device, timestamp, type or an index on value, location, device, timestamp, type. If you also added a non-clustered index on device this would include everything except value (unless you also have value in your clustering key in which case it'll include everything). Using these big non-clustered indexes would be efficient though (no extra row lookups needed) assuming you have enough memory for them not be a causes of IO thrashing.