Performance is absolutely a key concern. But in the same way a database query optimizer can (usually!) select an access plan, it should be possible to do the same for reactive update logic. At the systems level, reactive servers can be stateless rest servers that cluster. Within the rest server, a transaction can be analyzed to determine what *actually* changed, and prune the dependency graph and save (you are right - tons of) SQLs.
Slashdot Mirror
Performance is absolutely a key concern. But in the same way a database query optimizer can (usually!) select an access plan, it should be possible to do the same for reactive update logic. At the systems level, reactive servers can be stateless rest servers that cluster. Within the rest server, a transaction can be analyzed to determine what *actually* changed, and prune the dependency graph and save (you are right - tons of) SQLs.