Right, but with a single JSON column you have reduced RDBMS to a KeyValue store. Can the JSON document be indexed in some intelligent way on Postgres?
Isn't the SQL EntityStore already doing this in Zest? Love your; "YesSQL" Although I saw another funny meme;l NoSQL 2005 = No freaking SQL NoSQL 2010 = Not Only SQL NoSQL 2015 = Not Yet SQL Niclas On Mon, Sep 19, 2016 at 5:15 PM, Stanislav Muhametsin < stanislav.muhamet...@zest.mail.kapsi.fi> wrote: > On 19.9.2016 4:40, Niclas Hedhman wrote: > >> I agree that there is always a schema, and I don't think that anyone >> really >> disagrees with that. It is more a matter of "rigid" or "flexible" schema. >> The "rigid" world requires more process overhead to create and evolve, and >> over time end up with 500 columns that are mostly empty. >> > > Depends on how lazy the developer is in regard of keeping SQL schema up to > date with application schema. > That can be done with ALTER statements, which pretty much any relational > DB engine has these days. > The boundary between 'rigid' and 'flexible' schema is becoming blurry, > since e.g. PostgreSQL has been supporting 'json' column type now for a > while. > I think storing data in RDB using JSON should be investigated in Zest SQL > entitystore/indexing. > > From my own personal experience, I would never ever use NoSQL solutions > for any application I would develop - I think it is one of those useless > things spread by uneducated people. > Everything that NoSQL solution can do, the YesSQL solution can do better - > with proper tooling and modeling support, and with "think first, do then" > kind of approach. > Obviously, if one's working process lacks design/modeling/specsing of the > domain of one's application, NoSQL approach is more suitable. > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
