Question : Database Design Assistance Needed

Hello Experts-Exchange.  I am considering design alternatives for a SQL Server (2008) database and have a best-practices question (if there is a best practice for this).  The basic idea for the database is to utilize a 'main' table to hold a fixed number of sports data fields (ex. Total Points, First Downs) and then utilize another table (or multiple tables) to hold 'derived' data fields (derived from the main table's fields - ex. Average Points per First Down). I have a starting list of the derived fields that I am planning to implement (there are around 200) but that list will be growing over time. My question relates to what table structure makes the most sense when you know in advance that you will be adding fields. Two alternatives immediately come to mind:

  --  Use a single table to hold the all of the derived data fields (horizontally) and go through the pain of adding a new field each time I come up with one, including amending all INSERT and UPDATE sprocs and any other processes which rely on a fixed table schema (I can imagine many). It's doable but it strikes me as, well, inelegant to do it this way. I'm also not certain if there is a point at which a growing number of fields will start to bog down query performance - there could, over time, be hundreds of more added fields.
  --  Implement a cross-reference table to hold a list of the fields (field_id, field_name) and another, much narrower but far, far deeper 'derived stats' table to hold separate records for each field. Instead of 200+ fields and, say, 50000 records I'd end up with 8 fields but possibly 10 million records doing it this way. Adding new fields is simple - add a new record to the XREF table and start throwing new records into the derived stats table under that field_id.  Indexing will undoubtedly be easier this way as would, I expect, querying.  My principal concern with this strategy is query efficiency with the mandatory join plus the (possibly very) large number of rows that would end up in the 'derived' table. Assuming plenty of storage capacity and intelligently defined indexes should I be concerned with queries executing efficiently with this design?  I suppose if there is a row limit concern I could build separate tables to hold separate subgroups of the derived data but in that case I could end up having to do multiple queries to get a required set of data back, which certainly calls overall efficiency into question.

My gut tells me that the best solution is #2 or some variation of it, or possibly some third scenario. Ultimately it seems that it comes down to choosing between efficiencies lost with many columns vs. efficiencies lost with many rows plus a two-table join.  Is there a standard or best design practice which addresses this type of circumstance? Are there certain key design considerations that I should be focusing on optimizing with this type of scenario? Thanks in advance all..

Rick

Answer : Database Design Assistance Needed

there must be some conditions preventing the codes.

check if any of the follwing is true

* The control may be a type that can't receive the focus, such as a label.
* The control's Visible property may be set to No.
* The control's Enabled property may be set to