Servers Alive's database back-end I would go with the first option.
Breaking the information into separate tables would help with the database normalization (http://en.wikibooks.org/wiki/Relational_Database_Design/Normalization (http://en.wikibooks.org/wiki/Relational_Database_Design/Normalization)). From my experience, I don’t believe anything above 3NF would be of any benefit for SA. In general, designing to 3NF helps make any future product enhancements/redesigns/refactoring easier to implement. In general it provides more flexibility, there are a few scenarios which I could see if being a huge time saver. 1) John Smith who use to be alerted for 50 checks in building A is now also handling and additional 100 checks from buildings B and C. With the separate table it could be easy to make this change in bulk. 2) As an organization we now want all checks which monitor IIS to perform an IIS Reset on a server if a system has failed 10 times. In this scenario I have 40 IIS servers. 3) Twitter for whatever reason has been banned, how do I remove 20+ checks when I can’t remember which systems have the notifications among hundreds It’s all about scaling, it should be almost as easy to manage an SA instance for 50 checks as it would for 5,000. Patrick Goggins Senior Systems Administrator University of Wisconsin - Green Bay From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Dirk Bulinckx Sent: Friday, November 30, 2012 10:31 AM To: Servers Alive Discussion List Subject: [SA-list] Servers Alive's database back-end Some time ago it seemed to be a hot-topic to have a database backend for Servers Alive opposed to having a flat-text file like we have now. We are currently working on such a db backend (and no you won't need a SQL server or mySQL or Oracle server to run SA, SA will have its own simple build-in DB with option to use a big db system too). Having this db backend will give us more management options too so we think that this is a good thing to do. BUT as always we're faced with some open questions. Internaly (in SA I mean) we store the info of an entry is several large chuncks of data host info check info alerts info output info schedule info custom fields info In the db we could have one large table that combined host, check, output, schedule , custom fields And a "linked" table for the alerts (as you have several alerts per entry) This would mean at least something like 50 fields in one table OR we could have a table for host info check info output info schedule info custom fields info (and ofcourse for the alerts) (where for each host-record you would have 1 check record, 1 output record, 1 schedule record, 1 custom fields record) I can see pro's and cons for both systems. I would like to get some info/feedback from our users on how they would prefer this and why :-) Dirk Bulinckx Servers Alive - http://www.woodstone.nu (http://www.woodstone.nu) StellarDNS (DNS Hosting) - http://www.stellardns.com (http://www.stellardns.com) To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] (mailto:[email protected]) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
