gsvigruha

4 ms·

1.
by gsvigruha 8y ago
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.
2.
by gsvigruha 8y ago
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 = us
3.
by gsvigruha 8y ago
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 ide
4.
by gsvigruha 8y ago
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/
5.
by gsvigruha 8y ago
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.
6.
by gsvigruha 8y ago
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
7.
Cosyan – Transactional RDBMS with multi-table constraint logic(github.com)
44 points by gsvigruha 8y ago|14 comments