On 4/26/07, Joel D Canfield <joel at streamliine.com> wrote: > > Be careful. The data model you're suggesting will not enforce good > > data. > > true, in a sense. the example you include is actually an example of either a typo, or incredibly bad business logic. if I'm working on a project, and step one depends on step three being completed, and step three (somewhere in the past) depends on step one being completed, something's way bad wrong. > Yes, obviously there is an error in the logic somewhere. > of course, if the app can enforce intelligence and avoid typographical errors in entries, that's good. you mention 'making sense of this data' - since the data *doesn't* make sense, that's good, yes? > No, it's not really good. It's an error that your code cannot recover from. > or am I missing your point, matt? It's a minor point, really. I'm saying that this representation does not keep you from doing something stupid. There are a lot of tools in database management systems to keep you from doing something stupid (referential integrity, rules imposed by the structure itself, NOT-NULL fields, etc.). The more that has to be done by the application level, the more opportunity for errors. My comment about multiple moving parts... that's where stuff like this usually pops up. Someone's writing a batch job 2 years later to add task 1 as the precedent for everything that does not have a precedent. The author realizes the task 1 should be excepted (task 1 should not have itself as a precedent), but doesn't realize that this circular precedence must be checked for as well. The representation allows for circular precedence, so it therefore is something that must be avoided by all application code. It's similar to when MySQL did not support referential integrity. -- Matt Warden Cleveland, OH, USA http://mattwarden.com This email proudly and graciously contributes to entropy.