[gsvigruha]

Interesting, which DB is that? The ones i checked only have constraints on one table at a time (besides foreign keys).

The idea here is that constraints could span across multiple tables via chains of foreign keys. It might not be a new idea but i haven't seen any implementations yet (unless you count triggers).

[trurl]

We've had that for at least a decade in the LogicBlox database (which is based upon Datalog and not SQL). So you could say write

transfer_table(id, user, src, dest, amnt), amnt > 10000.0 -> auth_table(id, man), managed_by_table(user, man).

If you wanted to express that for a transfer involving more than 10,000 dollars that it must have been approved by the user's manager. Basically any logical formula can be used as a constraint. It's also possible to express basic temporal constraints like

+user_pass_table(user, pswd1), user_pass_table@prev(user, pswd2) -> pswd1 != pswd2.

So that says if the user's password has changed, and the user had a password in the previous transaction, they cannot be the same password.

[gsvigruha]

Thanks! I will check Datalog out, i have never used it (though i know Prolog a bit).

So the main difference is then that my version is SQL based: alter table transactions add constraint c_amount check (amount > 10000 -> auth.name = user.man.name) # or something similar, where you refer to other tables via a chain of foreign keys.

Another extra feature is that you can use aggregators in constraints in case of a one to many relationship: https://github.com/gsvigruha/cosyan/blob/master/src/main/res...

[trurl]

I'm not sure why you need to restrict constraints between tables to be based on foreign keys. I guess maybe that is a limitation inherent to SQL?

We also allow constraints over aggregations. Though our syntax does require giving the result of the aggregation a temporary "table" name so that it can be used as part of the constraint.

[gsvigruha]

I dont need to, thats a design choice i made for the moment for various reasons, one being to stay close to SQL concepts.

It seems like your DB is basically a Datalog version of what im trying to do in SQL.