No, you are not missing anything. My point there was how to build the
"constraints" part. Some DB's can be seen as providing a more
straightforward implementation, but that depends only from which angle
you approach the solution. In this case, my solution lays more in
validation (e.g., see http://guide.couchdb.org/draft/validation.html,
especially at the image
http://guide.couchdb.org/draft/validation/01.png) than in views. And
this is the constraint part which I was referring to.
Don't get me wrong, I meant no offense when I said it's more about logic
than the tool itself. By logic here I meant just the way you implement
the constraint and not the developer logic. I apologize if that created
any confusion with that.
On 10/20/2011 03:12 PM, Alexander Uvarov wrote:
This is not a problem in RDBMS with transactions and constraints. Am I
missing something?
On Thu, Oct 20, 2011 at 6:48 PM, CGS<[email protected]> wrote:
Hi Patrick,
I suppose that is more of logic than the tool itself and I suppose you may
enter the same problem in any DB you may change to (SQL or no-SQL).
