I think what the author is suggesting is that you can bridge some of the gap by a sort of non-SQL, quasi-relational data store. The major ways this is differentiated from the pure relational model is the general hostility towards representing information in well normalized relations and favoring a fairly object-oriented store instead.
This is not a new idea. PostgreSQL was originally designed with this sort of workflow in mind and now is pretty relational in outlook. In theory it is perfectly possible to transform one model into the other, provided adequate mappings, but at the same time one cannot reasonably derive one model from the other, which is why I disagree with the author's view that these are flip sides of the same coin.
Now, on to what is gained and what is lost. There are cases where the sorts of representation she is talking about are helpful (an in fact with recent PostgreSQL instances you can do them already).
On the other hand, the article isn't really clear about what the costs of this sort of representation are. The closest you get is the last line of his comparison table which contrasts query optimizer with developer/pattern. So what this implies is that such a system is optimized for developer/transaction workload and not for flexible reporting later. In other words, the developer is expected to know in advance all the uses the data will have so that the database can be properly optimized for this. Add new uses and this element becomes hard.
Similarly the ACID/BASE comparison also is telling in the sense that he is contrasting a system which is designed to give you accurate, consistent information when you ask for it to a system which is designed to tend towards a state of consistency, at least for older data. The "eventually consistent" part of his BASE definition ought to scare the pants off anyone interested in looking at how data in such a system could be put to decision support tasks.
Comments
I think what the author is suggesting is that you can bridge some of the gap by a sort of non-SQL, quasi-relational data store. The major ways this is differentiated from the pure relational model is the general hostility towards representing information in well normalized relations and favoring a fairly object-oriented store instead.
This is not a new idea. PostgreSQL was originally designed with this sort of workflow in mind and now is pretty relational in outlook. In theory it is perfectly possible to transform one model into the other, provided adequate mappings, but at the same time one cannot reasonably derive one model from the other, which is why I disagree with the author's view that these are flip sides of the same coin.
Now, on to what is gained and what is lost. There are cases where the sorts of representation she is talking about are helpful (an in fact with recent PostgreSQL instances you can do them already).
On the other hand, the article isn't really clear about what the costs of this sort of representation are. The closest you get is the last line of his comparison table which contrasts query optimizer with developer/pattern. So what this implies is that such a system is optimized for developer/transaction workload and not for flexible reporting later. In other words, the developer is expected to know in advance all the uses the data will have so that the database can be properly optimized for this. Add new uses and this element becomes hard.
Similarly the ACID/BASE comparison also is telling in the sense that he is contrasting a system which is designed to give you accurate, consistent information when you ask for it to a system which is designed to tend towards a state of consistency, at least for older data. The "eventually consistent" part of his BASE definition ought to scare the pants off anyone interested in looking at how data in such a system could be put to decision support tasks.