[thelist] Representing tasks in the database

[Matt Warden]

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.