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.

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

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

Probably the easiest if i link some of the doc to show some examples of usage: https://github.com/gsvigruha/cosyan/blob/master/src/main/res... https://github.com/gsvigruha/cosyan/blob/master/src/main/res...

Yes they are similar but they are procedural, i'm trying to do a declarative thing. I want to eliminate the need to figure out what constraint can a specific insert/delete on a specific table can break exactly.

Yes you're totally right i need to write the readme properly. You get faster development cycle by skipping the app layer altogether. It's a few sql statements vs java code/release/deploy. Performance: you don't need multiple queries for a constraint plus you can optimize from info within the DB. Dependency tracking: no need to figure out yourself which table/operation can break which constraint.