Ryan Bradetich <rbradetich@uswest.net> writes:
> the table would look like:
> 1 | Mon Feb 17 00:34:24 MST 2003 | p101 | user x has an invalid shell.
> 1 | Mon Feb 17 00:34:24 MST 2003 | p101 | user y has an invalid shell.
Ah, I see your point now. (Thinks: what about separating the "anomaly"
column into an "identifier" and a "complaint" column:
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | x | user has an invalid shell.
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | y | user has an invalid shell.
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | y | user has expired password.
2 | Mon Feb 17 00:34:24 MST 2003 | f101 | /foo | file has improper owner.
No, that doesn't quite work either, unless you are willing to make the
categories more specific. At which point the category and the anomaly
text become equivalent. Actually I'm wondering why you bother with the
category at all; isn't it implied by the anomaly text?)
> I agree with you, that I would not normally add the anomally to the
> index, except for the unique row requirement. Thinking about it now,
> maybe I should guarentee unique rows via a check constraint...
A check constraint won't be efficient either, at least not without a
supporting index. Possibly you could index just the host and timestamp
columns, which would not be unique but it would cut the number of rows
the constraint would need to examine to something manageable.
But I'm still thinking that enforcing uniqueness is a waste of time.
What exactly is so harmful about it if
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | user x has an invalid shell.
appears twice? How likely is that anyway (especially if you don't
truncate the timestamp precision)?
regards, tom lane