Re: offer a solution ?
At 01:49 PM 7/2/05, nephish wrote: i am writing a database to track what a bunch of electric monitors are doing. the status of the monitor changes almost daily. i need access to each monitor, when it changed, and i also need to track its history. Easy enough. but if i update a row in a table, i loose the old info. So i kinda cannot create a table referenced by a key of monitor number... i think that the easiest way, would be to create a seperate table for each monitor. Add a column for date changed instead. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: offer a solution ?
No, you don't want a table for each monitor. One table for the data will be _much_ easier to work with. If you want a history then you need to insert a new record for each datapoint that you get, with, as Frank suggested, a date/time column. How large your table will get will depend on the number of monitors and how often you retrieve data. Depending on how much history you need to keep, you can periodically trim the table by deleting all data older than N days (or hours, months, years). - Original Message - From: nephish [EMAIL PROTECTED] To: mysql mysql@lists.mysql.com Sent: Saturday, July 02, 2005 11:49 AM Subject: offer a solution ? Hey there, i have been messing around with MySQL for a little bit now. I have a question about how i might could do something. i am writing a database to track what a bunch of electric monitors are doing. the status of the monitor changes almost daily. i need access to each monitor, when it changed, and i also need to track its history. Easy enough. but if i update a row in a table, i loose the old info. So i kinda cannot create a table referenced by a key of monitor number... i think that the easiest way, would be to create a seperate table for each monitor... but there are almost a thousand monitors... will that become a nightmare ? can MySQL handle that kind of thing? a thousand tables in one database ? i have to be able to access each change in its history. how should i set this up? thanks for any suggestions. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: offer a solution ?
Actually, there should actually be two tables. One for columns that are static information about the monitor; the other with information that changes. should be in a separate table. OnlAt 12:30 PM 7/2/05, Jim McAtee wrote: No, you don't want a table for each monitor. One table for the data will be _much_ easier to work with. If you want a history then you need to insert a new record for each datapoint that you get, with, as Frank suggested, a date/time column. How large your table will get will depend on the number of monitors and how often you retrieve data. Depending on how much history you need to keep, you can periodically trim the table by deleting all data older than N days (or hours, months, years). - Original Message - From: nephish [EMAIL PROTECTED] To: mysql mysql@lists.mysql.com Sent: Saturday, July 02, 2005 11:49 AM Subject: offer a solution ? Hey there, i have been messing around with MySQL for a little bit now. I have a question about how i might could do something. i am writing a database to track what a bunch of electric monitors are doing. the status of the monitor changes almost daily. i need access to each monitor, when it changed, and i also need to track its history. Easy enough. but if i update a row in a table, i loose the old info. So i kinda cannot create a table referenced by a key of monitor number... i think that the easiest way, would be to create a seperate table for each monitor... but there are almost a thousand monitors... will that become a nightmare ? can MySQL handle that kind of thing? a thousand tables in one database ? i have to be able to access each change in its history. how should i set this up? thanks for any suggestions. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: offer a solution ?
depending on what you use this information for, you might want to keep two tables, one with the current information, and one of the history. it would keep the current one relatively small, but allow for looking up historical data if necessary. nephish wrote: Hey there, i have been messing around with MySQL for a little bit now. I have a question about how i might could do something. i am writing a database to track what a bunch of electric monitors are doing. the status of the monitor changes almost daily. i need access to each monitor, when it changed, and i also need to track its history. Easy enough. but if i update a row in a table, i loose the old info. So i kinda cannot create a table referenced by a key of monitor number... i think that the easiest way, would be to create a seperate table for each monitor... but there are almost a thousand monitors... will that become a nightmare ? can MySQL handle that kind of thing? a thousand tables in one database ? i have to be able to access each change in its history. how should i set this up? thanks for any suggestions. shawn -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
