> Interestingly enough, we never heard that SQL or the relational model was the root of all their problems.
i really think that sometimes SQL and the relational model is a problem. at least, the relational database design is a course in a university, along with (object oriented) programming. so, to properly use postgre or mysql in your sophomore web startup, you should know two things well, or have a clever db guy...
i have seen brilliant web programmers that design nightmare database schemas.
So relational data is hard but implementing appropriate consistency checks in your application is easy? Or do you just skip that second part and hope for the best?
imho, the second, except that some consistency is present ib document dbs: like in the order example, all order items will be within the document and wont be lost without losing the whole order.
no-one would ever use 'eventually consistent' databases for financial or trading data, i think. they're for higly scalable consumer web projects
Comments
> Interestingly enough, we never heard that SQL or the relational model was the root of all their problems.
i really think that sometimes SQL and the relational model is a problem. at least, the relational database design is a course in a university, along with (object oriented) programming. so, to properly use postgre or mysql in your sophomore web startup, you should know two things well, or have a clever db guy...
i have seen brilliant web programmers that design nightmare database schemas.
So relational data is hard but implementing appropriate consistency checks in your application is easy? Or do you just skip that second part and hope for the best?
imho, the second, except that some consistency is present ib document dbs: like in the order example, all order items will be within the document and wont be lost without losing the whole order.
no-one would ever use 'eventually consistent' databases for financial or trading data, i think. they're for higly scalable consumer web projects