Which design is better?

  • I'm not sure I totally understand your situation based on the examples that you have given. Your table design(s) show PropertyTracked as an integer, but your examples appear to have that as a varchar column.

    Based on my limited understanding, I do see a potential issue with your design. Will there never be a case where a business object will be updated multiple times thus causing a violation of the PK you have defined on BusinessObject and PropertyTracked? Unless the text "update" is really supposed to represent the OtherInformation column.

  • Sorry about the confusion. I have changed the original to show varchar. These tables are examples and not the real thing. I am trying to represent the idea which I guess I am not doing well.

    I do not feel a table should be un-constrained unless it has to be. Meaning something in the table beyond the ID field. It seems that when there is no constraint there is a better chance at bad data. Problem is in this solution the difference in design creates issues in development. I am trying to weigh out if the design is worth pushing for.

  • I agree that you should identify a natural key in each table, but I'm not sure you have one in either table structure you have defined.

    I'm assuming that this is auditing data changes, and I don't see how you can define a unique constraint on object and property if the property would be 'update', because this would mean you can only update a row one time. At the least you'd need to add a time to the audit trail as part of the unique key.

    Can you explain how the process will work? Is BusinessObject an ID for a row in a table? Is PropertyTracked a column?

Viewing 3 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply