Chris The answer is ONE table - perfomance is the matter of proper indexes...
I would recommend create compund primary key for this table - SENSOR_ID, UNIQUE_COLUMN In databases like Firebird this solution works perfectly - I use it all the time in warehouse management applications. Marcin ----- Original Message ----- From: "Chris Stebbing" <[EMAIL PROTECTED]> To: "Delphi DB List" <delphi-db@elists.org> Sent: Wednesday, June 11, 2008 8:29 AM Subject: Database Design Question > Hi All, > > I have a question on database design if I may. The application that > I will be working on is an industrial one where we will be logging > data from a number of different sensors all at differing rates. The > "current" data value is used to initiate actions and is always held > in memory, but past data is most commonly graphed regularly. By far > the largest amount of data is generated by logging these sensors, and > the most common use for this data is simply graphing. > > An installation could range anywhere from 5 sensors to 100 sensors. > > The main question I have is whether it would be better to have all > these sensors log into one table, or have them log into a separate > table per sensor. The amount of data can build up quite an amount > over time, and filtering one large table (or querying one large > table) takes an amount of time. Having the data already separated by > sensor would be a huge head start. > > Thanks for any comments and my apologies if this question is out of line > here. > > Regards, > Chris. > > -------------------------------------------------------------------------------- > _______________________________________________ > Delphi-DB mailing list > Delphi-DB@elists.org > http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-db > _______________________________________________ Delphi-DB mailing list Delphi-DB@elists.org http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-db
