In our current event design, the terminal name of any data container is
set to TargetDataName, and then all "parent" containers are listed,
slash-separated, in TargetDataContainer. This is true for tables in
databases, files in directories, attributes inside of directory objects
or classes, anything.

Others have suggested, however, that "attributes" or "properties" might
be a fundamentally different kind of data container, and should be
treated as such. So this would be things like attributes on a directory
object, file streams on an NT file, maybe properties on a directory
entry. We would have to define a new TargetDataAttribute field, then put
the parent Object name in TargetDataObject, and so on. The benefit would
be that a query looking for everything that happened to a particular
data object would be a little easier, and would capture creation of that
object and setting its attributes with a single filter expression.

On the other hand, the TargetDataAttribute field will likely almost
always be null.

What do you all think? Does it make more sense to present
attributes/properties as something fundamentally different from
objects/files/tables, etc?

What about a column name in a DB? Would it fall under this new kind of
data container?

DCorlette's Profile:
View this thread: