<HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-15"> <META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD> <BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>I sent this with the attachment a few days ago, but the attachment was big enough that the message requires approval. I thought I would resend this without the attachment so that I may get some more timely responses.</DIV> <DIV> </DIV> <DIV>--------------------------</DIV> <DIV> </DIV> <DIV>Ethan, et al<BR> <BR>Some of you may have seen the NDO schema drawing that I did a while back (I'll attach a new version with a few typos fixed). But a few things seem a little bit off. I'm not an expert at relational databases nor am I an nth normalization freak, but I have some suggestions for the NDO/Nagios 3.0 database schema.<BR> <BR>I would appreciate some feedback on my ideas.<BR> <BR>1. objects.name1 and objects.name2 shouldn't exist. The names of objects should live in their respective tables. Hosts should have a hostname and a alias field. Services should have a service_description field. Hostgroups should have a hostgroup_name and a hostgroup_alias field. etc. etc. etc. I believe this to be the case because they are unique to each object and cannot be generified-the result is a bunch of NULLs in the objects table. This also makes joining objects together ea sier/possible. In the current NDO database I couldn't use a join to show me all the servic es in a particular servicegroup. This could possibly be done with a subquery, but that seems excessive for a seemingly simple query.<BR> <BR>2. Host and Services should not be linked by name. At very least the id of the host and service object should be linked. But to truly model the Nagios works, it should be a many-to-many relationship with an association table. Since the NDO database with Nagios 2.x isn't the authority of data (the flat files still are) this shouldn't be a problem. And in Nagios 3.0 a relationship based on primary keys seems more appropriate.<BR> <BR>3. The instance table shouldn't need to be related to EVERY other table. In fact I think that a relationship to the objects table seems sufficient. That relationship should then carry throughout all other relationships. There are a few exceptions in table which don't link to the objects table.<BR> <BR>Marlo</DIV> <P><pre wrap>------------------------------------------------------------------------------ <P><pre wrap><width=80> NOTICE: This email message is for the sole use of the<br> intended recipient(s) and may contain confidential and<br> privileged information. Any unauthorized review, use,<br> disclosure or distribution is prohibited. If you are not the<br> intended recipient, please contact the sender by reply email<br> and destroy all copies of the original message. </pre></P> ------------------------------------------------------------------------------ </pre></P></BODY></HTML>