Re: [Perfparse-devel] Proposed specification for the conversion of the database

[Yves M. <yme...@li...>]

> One day all DBMS will be ANSI.  So the mountain in this case will come
> to Mohamed.  In the mean while, we can try to always keep as close as
> possible....

When all DBMS are ANSI, and if you use only the ANSI, you will not take b=
enefit of the
specific feature of them, and run slower than you would be able to.

Keep close, but don't hesitate to use specificities when it is good.
The more important is to make it easy to port perfparse to other dbms.


>  > 2.5  Store the range of warning and critical, as either an inside or
>  > outside range.  A value of NULL will indicate infinity.  A range
>  > type of NULL will indicate no value.
>  >
>  >
>  >>>>>>>>>>>>>> Not precise enough.
>  >
>  >
>  > I suggest NULL for infinite (-inf for start range and +inf for
>  > end range, because you cannot have +inf for start range, and you
>  > cannot have -inf for end range :)
>  >
>  > I suggest the default values when not recorded (0 for start range
>  > and +inf for end range, as specified on the nagiosplug plugins
>  > specification page).
>  >
>  > You also need something to say that the range is inverted (the @
>  > character in the range)
>
>
> This section is vague.  Can you look at section 4.3 where these ideas
> are expanded, and see whether this is acceptable?

Looks good.



>  > 4.1 The extraction of data for a graph between two dates can be
>  > completed as:
>  >
>  > SELECT * ...
>
>
>  >>>>>>>>>>>>>> For information, this is also possible with perfparsed
>  > since 0.103.1 if you enable file_output storage : telnet the
>  > perfparsed server and run this:
>  > history tm_start tm_end '1' '2' '3'
>
>
> I haven't tested this yet my self, but I am sure this will lead to some
> interesting applications.

If this is the start of a new thread, we'll split.
I just see one application as the CGI that draw the graphs. It can get th=
e data directly
from the server, without support of the database.
Tests of speed will be necessary to see if it is better or worse than ask=
ing the
database (like now). If speed is correct, maybe those who only need to gr=
aph performance
data can do it without the support of any database ? This is not the deat=
h of database
storage because statistics need it. And asking the database can be easier=
 when the
request is more complex than getting the data between two dates.

>  >   2.2 A check against the extra data will be completed to find out i=
f
>  > this extra data has been entered, against the key 'extra_id0'.  If
>  > this data has not been entered before, this should take place.
>
>
>  >>>>>>>>>>>>>> I suggest some option to do that check or not. You can
>  > also remove duplicates every night with perfparse-db-tool. Depends o=
n
>  > how much performance you need when inserting data in the database.
>
>
> Do you suggest writing *all* the extra data, one entry for each, then
> reducing the data in a nightly parse?

Ooops, forget that point :)
I was thinking to parsing the same line twice and entering it twice into =
the database :)

> I think this one will need to be settled experimentally.  Although your
> suggestion doesn't require a lookup on every line.  It does require
> massive insertion and deletion, which are both heavy activities for a
> database.  When we get there, we can test it.

With innodb, forget it. innodb databases cannot reduce their size.

> Another thing you may be suggesting is a flag to ignore *all* the extra
> data?  Leave the linkage as NULL?  This is an interesting idea is users
> did not want the warn, crit, max or min.  ?

Bad remarks because of misunderstanding (me) can give very good ideas (yo=
u) :)

Yves


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- Perfparse   - http://perfparse.sf.net/                           -