Saving 400 counters into table(s)?

Question 1

The maximum number of columns in a regular table is 1024 (see here), so you can't put 2,000 columns in one table.

That basically leaves two options:

Store each sub-element separately, with 400 columns (along with other identifing infromation, such as elemnt, data/time, and so on).
Use an entity-attribute-value model (EAV) model, with one row per element, sub-element, and value.

In general, I would lean toward storing one row for each sub-element. This would be especially true if the following are true:

The columns for each sub-element represent the same thing ("have the same name").
The columns for each sub-element have the same type.
The sub-elements always have all 400 columns.

If the columns are typically different, then I would think about an EAV model or a hybrid model.

Whether you need separate tables for Elements and Subelements depends on how the results are going to be used. For a complete data model, you might want to include them. If you are "just" doing numerical analysis on measures in the loaded data and not using the data for other purposes (archiving, reporting), then these entities might not be necessary.

Question 2

Looks like you can use an integer

I would just read and write a row at time

element int
subelement tinyint 
counterID smallint 
counterValue smallint

If you need to limit counterID to 1-400 you could do that with a trigger or a FK

select element, subelement, count(*) as count, min(counterValue ), max(counterValue )  
  from table 
 group by element, subelement

Question 3

A (note: not "the") right way, mapping the hierarchy to relations with constraints:

Element { elementid, elementnumber }

Unique over the combination of columns, with the id being the PK. If you need to track the data historically, maybe use a timestamp for the id, such as smalldatetime.

Subelement { elementid, elementnumber, subelementnumber }

Unique over the whole set, with the first two columns being FKs, their combination making a PK.

Counter { elementid, elementnumber, subelementnumber, counternumber, counter }

Unique over the whole set, with the first three columns as FKs, their combination making a PK.

All the core data exists in counter, and is constrained by the other tables' values. If you fill it in, "root to leaf," the PK/FKs will be neatly satisfied, you'll have smaller tables to group and join by, and if you want to chomp on a whole mess of values, queries on Counter, with a couple WHERE clauses, will get the job done.

If you know you'll never have more than 250 elements, a tinyint should do for the element number and subelement number, with smallint handling the counter number.