I'm assuming you're measuring something from each unit (I'm guessing device?) out on the field?
Taking a quick glance at your table, I could see three tables being created to normalize things out. You have particular units at a particular location. That can be one table. Another table would be the testing event. This is where you're recording the date and time an event is happening, and can even be labeled for automation or manual tests with an additional field. The third table would be the raw data received. The joins would point PK->FK from Location.LocationID to Event.LocationID, then PK->FK for Event.DataID to Data.DataID. This way your raw data sits in one table, nothing is replicated, it is as low level as it gets. Your testing events can be viewed without the knowledge of what location was tested, or what the actual results of the events were. Each location can be added or removed or modified without affecting the test events or test results. Since a particular test event is going to pull in data, there isn't need to grind down to further tables. You're always (I'm assuming) going to get a result for all testing values, so, that all should be in one table. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
