Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
In-Reply-To: <CADmm+Kd+iGVEMUMqXCz20Kv3NzJQ+Pp9+632e4TnCxsL4+meYA@mail.gmail.com>
References: <CADmm+KfpLwUkwugYiTSUpbabMT2FPYF6bA+dk_m0bBxUVw4E-g@mail.gmail.com>
 <57AB8CD5.404@gmail.com> <9df0b572740e557f6b3e3a5c4d4cdab5@nosphere.org>
 <CADmm+Kf5gSuy-uDB7kAoNZpg0nzFPd7cEgejpsxShrOSXWS1rw@mail.gmail.com>
 <CAH+CGsKfZ8X_0OdmCv-qL9KnemU-T6S1KgVjgHxd=YxmBYLAHw@mail.gmail.com>
 <CADmm+KduF=SZ+RRjekzo=yveE_D053-Zi1kyatNx5nJ+skiA-Q@mail.gmail.com>
 <03114e35-ea86-3aef-e0ec-a1dadfb4829b@zest.mail.kapsi.fi> <CADmm+Kd+iGVEMUMqXCz20Kv3NzJQ+Pp9+632e4TnCxsL4+meYA@mail.gmail.com>
From: Jiri Jetmar <juergen.jetmar@gmail.com>
Date: Tue, 20 Sep 2016 23:08:19 +0200
Message-ID: <CAH+CGsJyKAVJC6OEEhmS9jOYuo3f3vP4Rq9oAWwMVBSexXEKjw@mail.gmail.com>
Subject: Re: JPA?
To: dev@zest.apache.org
Content-Type: multipart/alternative; boundary=001a113ccd8207901c053cf6d47b
archived-at: Tue, 20 Sep 2016 21:08:27 -0000

--001a113ccd8207901c053cf6d47b
Content-Type: text/plain; charset=UTF-8

JSON Indexing @Postgresql :

https://www.postgresql.org/docs/9.4/static/datatype-json.html

should work, looks promising so far.

The point with NoSQL is from my perspective i) the sheer amount of
accumulated data and ii) the need to "interact" with those data, like index
them, modify them, etc. Further I think we have to distinguish between
NoSQL - the concept, SQL - the CRUD(Q)  expression and the relational
repository design. This are simply different things.

I mean the relational world using SQL expression for interactions with the
repository was just fine as long as one could build a "SQL-cluster" with
just few nodes. This is my personal experience based on some Oracle DB
setups where I was involved in. At the other side they are relational
setups with hundreds of nodes, e.g. the Skype Backoffice is (was) build on
top of Postgresql.

Independently of that that, things starts to be complicated in the SQL
world with large data when you are submitting e.g. a inner JOIN statement
in a transactional INSERT expression, where the tables are located  (the
data) on different nodes, simply because of a single node limit. Together
with other relational features like the visibility of data (level of
isolation) things are that complicated that the whole thing does not scale
further. Therefore the NoSQL concept was born, where the applications are
(partially) responsible for the data management - a bit like in the pre-SQL
era. Due to this responsibility for data handling, NoSQL application are
more complex then purely SQL based and require longer time to market. So
from my perspective, whenever possible, one should use SQL and
transactional (ACID) repositories.

Now on Zest, we have the JSON serialization of Entities and we "degrade"
relational repositories to KeyValue storage engines. We should change it
and also allow external modeled schemas.

I would like to work on this task. Therefore smart ideas are highly welcome
! :-)

Cheers,
Jiri


2016-09-20 1:02 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:

> 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.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
>

--001a113ccd8207901c053cf6d47b--