<div dir="auto"><div dir="ltr"><div dir="ltr">On Fri, 5 Jun 2020 at 17:23, Nicholas Krause via talk <<a href="mailto:talk@gtalug.org" target="_blank" rel="noreferrer">talk@gtalug.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Greetings,<br>
<br>
I'm aware a few people here keep up more with certain database trends<br>
then me including Chris Browne. I'm aware of the newest standard of<br>
SQL supporting JSON.  Does anyone have any thoughts on this or how<br>
it may affect things going forward in the database world.<br>
<br>
Postresql supported operators before but seems their moving to the<br>
current SQL standard implementation, last I checked.</blockquote><div> </div></div><div>The PostgreSQL JSON types had been getting some pretty positive <br></div><div>attention, and with what got drawn into JSONB around the 9.5 days</div><div><a href="https://www.postgresql.org/docs/9.5/functions-json.html" target="_blank" rel="noreferrer">https://www.postgresql.org/docs/9.5/functions-json.html</a></div><div>made it pretty attractive in ways that XML never got to.</div><div><br></div><div>JSONB was interesting in that it compresses material and provides</div><div>indexing inside the JSON document, so you can have functional <br></div><div>indexes on parts of the content, as well as GIN indexes <br></div><div><br></div><div>Sensible use of it shouldn't make all the usual relational bits go</div><div>away; tis best to define a table that has JSON with some mix</div><div>of JSON and other stuff.</div><div><br></div><div>ntdb=# create table our_users( user_id serial primary key);<br>CREATE TABLE<br>ntdb=#<br>ntdb=# create table message_encoded_json (<br>ntdb(#   id serial primary key,<br>ntdb(#   user_id integer not null references our_users(user_id) on delete restrict,<br>ntdb(#   created_on timestamptz default now(),<br>ntdb(#   json_blob jsonb<br>ntdb(# );<br>CREATE TABLE<br>ntdb=# create index msg_gin on message_encoded_json using gin (json_blob jsonb_ops);<br>CREATE INDEX<br>ntdb=# create index msg_gin2 on message_encoded_json using gin (json_blob jsonb_path_ops);<br>CREATE INDEX</div><div><br></div><div>I'm not at all sure which of those indexes are preferable; that hasn't made it into my</div><div>knowledge.</div><div><br></div><div>The above is the sort of pattern that makes sense; if there's a wild bundle of stuff that <br></div><div>might go into a table of billing transactions, you'd still have ordinary traditional attributes</div><div>like a transaction ID, transaction types, and dates in the lifecycle that are pretty</div><div>universal.</div><div><br></div><div>I think I was in one of Oleg Bartunov's talks on their own "jsonpath" query language,</div><div>possibly this one <a href="https://www.pgcon.org/2019/schedule/events/1274.en.html" target="_blank" rel="noreferrer">https://www.pgcon.org/2019/schedule/events/1274.en.html</a></div><div><br></div><div>The query system for JSON bits seemed pretty brain-melty; remembering what</div><div>little sets of characters going together searched for whatever seemed painfully</div><div>similar to, oh, say, APL.<br></div><div><br></div><div><a href="https://github.com/obartunov/sqljsondoc/blob/master/README.jsonpath.md" target="_blank" rel="noreferrer">https://github.com/obartunov/sqljsondoc/blob/master/README.jsonpath.md</a></div></div></div>