Many to many relationship for recursive table

Question

HI friends,
I have a use-case where I have several tasks that are inter-dependent on each other. Like one task will execute only if other tasks (which can be more than one) are successful. I am not able to decide what the database design should be for this. If there should be a relationship table with a self-join something like this-
CREATE TABLE Item (
ItemId int,
status varchar,
PRIMARY KEY(ItemId));
CREATE TABLE Item_Relation (
itemId int,
dependsOnItem int,
PRIMARY KEY(itemId, dependsOnItem),
FOREIGN KEY(itemId) REFERENCES Item (ItemId),
FOREIGN KEY(dependsOnItem) REFERENCES Item (ItemId));
is it recommmended because this is the only solution I see for this?
Thanks.

Answer 1

Looks like your trying to embedd business logic in the database tables. It should be in your java project only.
I suggest you keep your database simple with basic associations between tables (foreign keys). The database
is for storing data that many applications aside from yours will want to use. Your specific business logic requirements
should not be in it.
In your java code, you can use transactions in your sql to rollback if something isn't the way it should be.
However, I would not suggest you put your task verification problem code handling in the rollback block of code.
Instead, I suggest you query the database tables and determine if the previous tasks are ok to do the current unit of work.
If so, perform the unit of work (say, write to some other database table). If not, return a message on what the problem is
(better yet, have a validation function that verifies the pervious tasks have been done). All of that should be in a transaction
to play it safe. Why you ask?
The problem is, even if your validation function says the previous tasks are complete, by the time you perform the new unit
of work, the database may have changed and the validation is not longer valid. Therefore you rollback may still occur (ensures the
data in the database is not in an invalid state) Normally in that case, you rollback and tell the user to repeat the operation
(see optomistic concurrency). Exactly how you plan on handling these side issues is up to you.