polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: JPA?
Date Mon, 19 Sep 2016 23:02:15 GMT
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


On Mon, Sep 19, 2016 at 5:15 PM, Stanislav Muhametsin <
stanislav.muhametsin@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message