[trurl]

It isn't really clear to me how this differs from usual database integrity constraints? However, I'm not familiar with what typical SQL databases provide.

The database I work on has had sophisticated integrity declarative integrity constraints for a decade now, so it seems surprising that this would be considered something new.

[snaky]

Integrity (consistency) was the biggest point of relational database theory itself.

> The true importance of relational theory is highlighted by the title of the original (and considerably shorter) version of Codd’s first paper. That version predated the published version by a year, and the title was “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks.”[1] The title of this unpublished version emphasizes that the real importance of relational theory is that it provides a rigorous method of asserting arbitrarily complex consistency constraints that must be satisfied by the data within the database.

https://iggyfernandez.wordpress.com/2013/04/24/whats-so-sacr...

[1] http://www.liberidu.com/blog/images/rj599.pdf

[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.