Hi Wes,
err not CID, sorry didn't have the table in front of me.. the sig_id.
I realize that all the other tables are involved with the sig_id
(obviously) hense the plugin re-write. Theoretically the SIG_SID and
SIG_ID are the same, just diff values. Again, this is dealing with the
SIGNATURE TABLE, everything now seems to rely on the SIG_ID instead of
the SIG_SID, that was my whole point. So instead of auto-incrementing
the SIG_ID in the table, make it equal to the SIG_ID upon insertion
until we can safely get rid of it.
once more: Even this view is not correct at all...
The SIG_ID and SIG_SID are not the same. The big difference is that
you may have the same signature ID with different revisions. Hence
the keyword "rev". But you also get a new SIG_ID if you change the
classification and more worse the priority.
If you use several snort sensors it may be a good idea to use even
several priorities. A web attack in front of a mail server would
get a minor priority than against a webserver.
So, there is a good reason for this. And I don't think that this
design is the bottleneck of the database.
This is more the combination of the sensor ID and the counter per
sensor, hence the SID/CID pair.
Best regards
Dirk
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
