Iterative thinking dulls the mind...

After having some more research online, I have come to the conclusion that developers are not always clever people. Maybe it's the iterative thinking that stands in the way of enlightenment..? Anyway, you can read some really stupid things online on this topic. Like this one:

"The problem with triggers is that they cannot be "seen." It is easy to view table relationships, constraints and indexes in the database. On the client-application side, it is also simple to analyze the code. On the other hand, triggers are automatic programs defined in the database that execute behind the scenes as part of the command that fired them. It is hard to follow their logic and in time, it is easy to forget about the triggers in SQL Server, especially if they are not well-documented.

Here are some trigger design tips to keep in mind:

1. Avoid using nested triggers
   By default, if a trigger is changing other tables, the triggers declared for these tables are not fired. The "allow nested triggers" server option sets databases to have the opposite behavior. Triggers are nested when a trigger performs an action that initiates another trigger, which can initiate another trigger and so on. Triggers can be nested up to 32 levels. It is very difficult to follow the logic of nested triggers and they can affect performance.
2. Avoid using recursive triggers
   There are two types of recursion:
   
   • Direct recursion occurs when a trigger fires and performs an action that causes the same trigger to fire again. You can prevent that from happening by setting the "recursive trigger" database option to OFF.
   
   
   • Indirect recursion occurs when a trigger fires and performs an action that causes a trigger on another table to fire. This second trigger causes an update to occur on the original table, which causes the original trigger to fire again. This can be prevented with the "nested triggers" server option."

I'm sorry, but that is just stupid. Ok, you get some of hte same issues as with threads using triggers, but if you plan it carfully, you should have no problem. Like in my example from my previous post, the creation of a transitive closure of a graph, nothing could logically go wrong. Worst case scenario, the TC will have been built for n-1 cases when the last trigger is executed. This means an entire run is done just because of one missing piece of the TC, but hey! Not a big problem, and really not dangerous. If SQLite featured "FOR EACH STATMENT" triggers, this would not even be a problem at all.

So why state that triggers should be avoided? Pointers are powerful and therefore also dangerous too. So, maybe they should not be used either? :-) Good luck developing software this way....

I think more functional programming thinking is needed, and less interative thinking.